Le client MCP sert de pont de communication entre votre serveur et les serveurs MCP. C'est votre point d'accès à tous les outils qu'un serveur MCP fournit, gérant l'échange de messages et les détails du protocole afin que votre application n'ait pas à le faire.
Communication agnostique au transport
Une des forces clés de MCP est d'être agnostique au transport - une façon élégante de dire que le client et le serveur peuvent communiquer via différents protocoles selon votre configuration.
La configuration la plus courante exécute à la fois le client MCP et le serveur sur la même machine, communiquant via l'entrée/sortie standard. Mais vous pouvez également les connecter via :
- HTTP
- WebSockets
- Divers autres protocoles réseau
Types de messages MCP
Une fois connectés, le client et le serveur échangent des types de messages spécifiques définis dans la spécification MCP. Les principaux avec lesquels vous travaillerez sont :
ListToolsRequest/ListToolsResult : Le client demande au serveur « quels outils fournissez-vous ? » et reçoit en retour une liste des outils disponibles.
CallToolRequest/CallToolResult : Le client demande au serveur d'exécuter un outil spécifique avec des arguments donnés, puis reçoit les résultats.
Comment tout fonctionne ensemble
Voici un exemple complet montrant comment une requête utilisateur circule à travers l'ensemble du système - depuis votre serveur, via le client MCP, vers des services externes comme GitHub, et retour vers Claude.
Disons qu'un utilisateur demande « Quels dépôts ai-je ? » Voici le déroulement étape par étape :
- Requête utilisateur : L'utilisateur soumet sa question à votre serveur
- Découverte des outils : Votre serveur doit savoir quels outils sont disponibles pour les envoyer à Claude
- Échange de liste d'outils : Votre serveur demande au client MCP les outils disponibles
- Communication MCP : Le client MCP envoie une
ListToolsRequestau serveur MCP et reçoit unListToolsResult - Requête à Claude : Votre serveur envoie la requête de l'utilisateur ainsi que les outils disponibles à Claude
- Décision d'utilisation d'outils : Claude décide qu'il doit appeler un outil pour répondre à la question
- Demande d'exécution d'outil : Votre serveur demande au client MCP d'exécuter l'outil spécifié par Claude
- Appel API externe : Le client MCP envoie une
CallToolRequestau serveur MCP, qui effectue l'appel API GitHub réel - Retour des résultats : GitHub répond avec les données des dépôts, qui reviennent via le serveur MCP sous forme de
CallToolResult - Résultat de l'outil vers Claude : Votre serveur renvoie les résultats de l'outil à Claude
- Réponse finale : Claude formule une réponse finale en utilisant les données des dépôts
- L'utilisateur obtient la réponse : Votre serveur délivre la réponse de Claude à l'utilisateur
Oui, ce flux implique de nombreuses étapes, mais chaque composant a une responsabilité claire. Le client MCP abstrait la complexité de la communication avec le serveur, vous permettant de vous concentrer sur la logique de votre application tout en ayant accès à de puissants outils externes et sources de données.
Comprendre ce flux est crucial car vous verrez tous ces éléments lors de la construction de vos propres clients et serveurs MCP dans les sections à venir.