Introduction au Model Context Protocol

Vous savez construire des outils — et vous savez donc ce que chacun coûte : un schéma, une implémentation, des tests, de la maintenance. Le Model Context Protocol (MCP) part de ce constat : c’est une couche de communication qui fournit à Claude du contexte et des outils sans vous obliger à écrire une quantité fastidieuse de code d’intégration. Pensez-y comme un moyen de déléguer la définition et l’exécution des outils à des serveurs MCP spécialisés, plutôt que de tout gérer vous-même.

Le problème sans MCP

Donnons au problème sa taille réelle. Supposons que vous construisez une interface de chat où les utilisateurs peuvent interroger Claude sur leurs données GitHub. Un utilisateur pourrait demander : « Quelles pull requests sont ouvertes dans tous mes dépôts ? »

Sans MCP, vous devriez créer tous les outils d’intégration GitHub vous-même : des schémas et des fonctions pour chaque fonctionnalité que vous souhaitez exposer (dépôts, pull requests, issues, projets, etc.) — avec, pour chacun, les appels d’API, l’authentification, la pagination, les cas d’erreur.

GitHub possède des centaines de fonctionnalités. Construire un chatbot GitHub complet nécessiterait d’écrire, tester et maintenir un nombre considérable d’outils — chacun avec sa définition de schéma et son implémentation. Et le plus frustrant : ce travail n’a rien de spécifique à votre produit — chaque équipe qui connecte Claude à GitHub réécrit exactement le même code que la vôtre.

Comment MCP résout ce problème

MCP déplace la responsabilité de la définition et de l’exécution des outils de votre serveur vers des serveurs MCP dédiés. Au lieu d’écrire tous ces outils GitHub, ils sont créés et exécutés à l’intérieur d’un serveur MCP spécialisé — votre application s’y connecte, découvre les outils disponibles, et les présente à Claude comme s’ils étaient les siens.

Le serveur MCP agit comme un wrapper autour des fonctionnalités de GitHub, fournissant des outils prêts à l’emploi que vous pouvez utiliser sans les implémenter vous-même. Et parce que le protocole est standardisé, l’effet dépasse votre projet : un serveur écrit une fois sert tous les clients compatibles — le vôtre, ceux d’autres équipes, ou des applications comme Claude Code. Chaque nouveau serveur enrichit tout l’écosystème.

Principe clé : Les serveurs MCP fournissent des schémas d’outils et des fonctions déjà définis pour vous. Ils encapsulent des intégrations complexes en composants réutilisables que n’importe quelle application peut connecter.

Questions fréquentes

Qui crée les serveurs MCP ?

N’importe qui peut créer une implémentation de serveur MCP — le protocole est ouvert, les SDK publics, et nous écrirons d’ailleurs le nôtre dans quelques leçons. Souvent, les fournisseurs de services eux-mêmes publient leurs propres implémentations officielles — par exemple, AWS pourrait publier un serveur MCP officiel avec des outils pour ses différents services — maintenues par les équipes qui connaissent le mieux leurs API.

MCP vs appels API directs

Quand vous appelez une API directement, vous devez écrire vous-même les définitions d’outils — c’est tout le travail de la section précédente. Avec MCP, quelqu’un d’autre a déjà écrit ces définitions et fonctions — elles sont packagées dans le serveur MCP. Le HTTP sous-jacent est peut-être identique ; c’est le travail de définition et de maintenance qui change de mains.

MCP vs utilisation d’outils classique

C’est la confusion la plus courante, et la distinction structure tout le module :

• L’utilisation d’outils décrit le mécanisme par lequel Claude peut appeler des fonctions
• MCP décrit qui est responsable de créer et maintenir ces outils

Le mécanisme ne change pas d’un iota : Claude reçoit des schémas, émet des demandes, consomme des résultats — il ne voit aucune différence entre un outil MCP et un outil maison. Avec MCP, ce travail a simplement déjà été fait pour vous.

Points clés à retenir

• MCP délègue définition et exécution des outils à des serveurs spécialisés, écrits une fois pour tous
• Le problème visé : réécrire dans chaque application les mêmes intégrations massives (GitHub, AWS…)
• Protocole standardisé = effet d’écosystème : un serveur sert tous les clients compatibles
• Les fournisseurs publient souvent des serveurs officiels — des intégrations prêtes à l’emploi
• MCP ne change pas le tool use : il règle la provenance des outils, le mécanisme reste identique