Introduction au MCP

Vous savez désormais construire des outils : fonction, schéma, boucle de conversation. Vous savez aussi ce que cela coûte — chaque outil demande sa définition, sa validation, sa 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 que vous ayez à écrire tout le code d’intégration. Au lieu de construire chaque fonction d’outil vous-même, MCP délègue ce travail à des serveurs spécialisés — écrits une fois, par quelqu’un, pour tout le monde.

Le problème que résout le MCP

Mesurons d’abord le problème. Imaginez une interface de chat où les utilisateurs interrogent Claude sur leurs données GitHub. GitHub a une surface fonctionnelle massive : dépôts, pull requests, issues, projets, actions, releases… Pour couvrir tout cela avec les techniques de la section outils, il faudrait écrire un nombre considérable de schémas d’outils et de fonctions — chacun avec ses appels d’API, sa gestion d’erreurs, sa pagination, son authentification. Des semaines de travail d’intégration qui n’ont rien à voir avec votre produit. Et le pire : l’équipe d’à côté, qui construit une autre application GitHub + Claude, est en train d’écrire exactement le même code.

Comment MCP change la donne

MCP déplace la charge des définitions et de l’exécution des outils de votre application vers des serveurs MCP. Au lieu d’écrire toutes les intégrations GitHub, quelqu’un d’autre crée un serveur MCP pour GitHub contenant tous les outils nécessaires — schémas et implémentations. Votre application s’y connecte, découvre les outils disponibles, et les présente à Claude comme s’ils étaient les siens. Le duo découverte/exécution que vous écriviez à la main devient un protocole standardisé : le travail d’intégration est fait une fois, dans le serveur, et tous les clients en héritent. Votre code, lui, se recentre sur ce qui vous appartient en propre — l’expérience de votre application.

Qui crée les serveurs MCP

N’importe qui peut créer un serveur MCP — le protocole est ouvert et les SDK sont publics, c’est d’ailleurs ce que nous ferons dans les prochaines leçons. Mais l’intérêt du standard est ailleurs : souvent, les fournisseurs de services eux-mêmes publient des implémentations officielles — AWS pour ses services, par exemple — maintenues par ceux qui connaissent le mieux leur API. Un écosystème entier de serveurs existe déjà, couvrant les outils de développement, les bases de données, les services web courants : autant d’intégrations que vous n’aurez jamais à écrire.

Questions fréquentes

Quelle différence avec un appel API direct ? Les serveurs MCP fournissent des schémas et fonctions d’outils déjà définis. En appelant une API directement, vous devez écrire ces définitions vous-même — le HTTP est le même, c’est le travail de définition et de maintenance qui change de mains.

MCP et tool use, c’est pareil ? Non, et la distinction structure toute la section. Le tool use est le mécanisme par lequel Claude demande et reçoit des appels d’outils — il ne change pas d’un iota avec MCP. Les serveurs MCP fournissent des schémas et fonctions pré-construits qui alimentent ce mécanisme. MCP répond à une seule question : qui fait le travail de création et de maintenance des implémentations. Claude, lui, ne voit aucune différence — des outils, des résultats.

Points clés à retenir

• MCP délègue la définition et l’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…)
• Votre application se connecte, découvre les outils du serveur et les présente à Claude comme les siens
• Les fournisseurs publient souvent des serveurs officiels — un écosystème d’intégrations prêtes à l’emploi
• MCP ne remplace pas le tool use : il industrialise la provenance des outils, le mécanisme reste identique