Introduction à MCP

La section Tool Use vous a appris à donner des capacités à Claude — et aussi ce que cela coûte : chaque outil exige son schéma, son implémentation, ses tests, sa maintenance. Le Model Context Protocol (MCP) attaque ce coût frontalement : c’est une couche de communication qui fournit à Claude du contexte et des outils sans vous obliger à écrire une montagne de code d’intégration. Au lieu de construire chaque fonction outil vous-même, MCP délègue cette charge à des serveurs spécialisés, développés et maintenus en dehors de votre application.

Le problème que résout MCP

Donnons au problème sa taille réelle. Imaginons que vous construisez une interface de chat où les utilisateurs peuvent interroger Claude sur leurs données GitHub. Sans MCP, vous devriez créer des outils pour chaque opération GitHub que vous voulez supporter : repositories, pull requests, issues, projets, et bien plus. La fonctionnalité de GitHub est massive — cela représente une quantité énorme de code à écrire, tester et maintenir : les appels d’API, l’authentification, la pagination, les cas d’erreur, pour des dizaines d’opérations. Et ce travail n’a rien de spécifique à votre produit — la preuve : chaque équipe qui connecte Claude à GitHub réécrit exactement le même code que la vôtre. C’est ce gâchis d’efforts dupliqués que MCP élimine.

Comment fonctionne MCP

MCP déplace la charge des définitions et de l’exécution des outils de votre application vers des serveurs MCP dédiés. Au lieu d’écrire tous ces outils GitHub vous-même, vous vous connectez à un serveur MCP GitHub qui les a déjà implémentés — schémas compris. L’architecture de base tient en une phrase : un client MCP (dans votre application) se connecte à des serveurs MCP qui contiennent des outils, des prompts et des ressources ; chaque serveur agit comme une interface standardisée vers un service externe.

Le mot « standardisée » porte tout l’intérêt du protocole : parce que clients et serveurs parlent le même langage, n’importe quel client fonctionne avec n’importe quel serveur. Un serveur écrit une fois sert toutes les applications compatibles — la vôtre, celles d’autres équipes, ou des applications grand public comme Claude Desktop. C’est l’effet d’écosystème : chaque nouveau serveur enrichit tous les clients existants, et réciproquement.

Questions fréquentes

Trois questions reviennent systématiquement à la découverte de MCP.

Qui crée les serveurs MCP ? N’importe qui peut créer une implémentation de serveur — le protocole est ouvert et les SDK publics ; nous écrirons le nôtre dans quelques leçons. Souvent, les fournisseurs de services créent leurs propres implémentations officielles, maintenues par les équipes qui connaissent le mieux leurs API. Un écosystème entier existe déjà : outils de développement, bases de données, services cloud.

En quoi est-ce différent d’appeler les API directement ? Quand vous appelez l’API d’un service directement, vous devez quand même écrire les schémas et les implémentations vous-même — c’est tout le travail de la section Tool Use. Les serveurs MCP fournissent ces schémas et fonctions déjà définis : le HTTP sous-jacent est peut-être le même, mais le travail de définition et de maintenance a changé de mains.

MCP est-il juste la même chose que le Tool Use ? Non, et cette distinction structurera toute la section. Le Tool Use est le mécanisme par lequel Claude appelle des fonctions — il ne change pas d’un iota. MCP concerne qui fournit ces fonctions. Les deux sont complémentaires : MCP réduit le travail de développement en fournissant des outils pré-implémentés, que Claude consomme via le Tool Use exactement comme il consommait vos fonctions locales. Du point de vue du modèle, rien ne distingue un outil MCP d’un outil maison.

Points clés à retenir

• MCP délègue définition et exécution des outils à des serveurs spécialisés — fini le code d’intégration dupliqué
• Le problème type : réimplémenter dans chaque application les mêmes dizaines d’outils (GitHub, AWS…)
• Architecture : votre client MCP se connecte à des serveurs qui exposent outils, prompts et ressources
• Protocole standardisé = effet d’écosystème : un serveur écrit une fois sert tous les clients compatibles
• MCP ne remplace pas le Tool Use : il change la provenance des outils, pas le mécanisme d’appel