Le client MCP sert de pont de communication entre votre serveur et les serveurs MCP. Considérez-le comme votre point d'accès à tous les outils qu'un serveur MCP fournit. Lorsque vous avez besoin d'utiliser une fonctionnalité externe, le client gère pour vous tout le passage de messages et les détails du protocole.
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 entre eux en utilisant différentes méthodes de communication. La configuration la plus courante exécute à la fois le client MCP et le serveur sur la même machine, où ils communiquent via l'entrée/sortie standard.
Mais vous ne vous limitez pas à cette approche. Les clients et serveurs MCP peuvent également se connecter via :
- HTTP
- WebSockets
- Divers autres protocoles réseau
Types de messages
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 complète des fonctionnalités disponibles.
CallToolRequest/CallToolResult : Le client indique au serveur « exécute cet outil spécifique avec ces arguments » et reçoit les résultats de l'exécution.
Exemple de flux complet
Voici comment toutes les pièces fonctionnent ensemble dans un scénario réel. Disons qu'un utilisateur demande « Quels dépôts ai-je ? » - voici le flux de communication complet :
Le processus commence lorsqu'un utilisateur soumet sa question à votre serveur. Mais avant que votre serveur puisse demander de l'aide à Claude, il doit savoir quels outils sont disponibles.
Votre serveur demande au client MCP une liste d'outils. Le client envoie une ListToolsRequest au serveur MCP et reçoit en retour une ListToolsResult avec tous les outils disponibles.
Maintenant votre serveur a tout ce qu'il faut pour faire la requête initiale à Claude : la question de l'utilisateur plus la liste des outils disponibles.
Claude analyse les outils et décide qu'il doit en appeler un pour répondre à la question. Il répond avec une demande d'utilisation d'outils.
Votre serveur reconnaît que Claude veut exécuter un outil, mais votre serveur n'exécute plus les outils directement - c'est le travail du serveur MCP. Il demande donc au client MCP d'exécuter l'outil avec les arguments spécifiés par Claude.
Le client MCP envoie une CallToolRequest au serveur MCP, qui effectue ensuite la requête réelle à GitHub pour récupérer les dépôts de l'utilisateur.
GitHub répond avec les données du dépôt, que le serveur MCP enveloppe dans un CallToolResult et renvoie au client MCP.
Le client MCP transmet le résultat de l'outil à votre serveur, qui l'envoie ensuite à Claude dans le cadre d'un message de suivi.
Enfin, Claude dispose de toutes les informations dont il a besoin et formule une réponse du type « Vos dépôts sont... » qui est renvoyée à l'utilisateur via votre serveur.
Oui, ce flux implique de nombreuses étapes, mais chaque composant a une responsabilité claire. Le client MCP fait abstraction de la complexité de la communication avec le serveur, vous permettant de vous concentrer sur la construction de la logique de votre application tout en ayant accès à de puissants outils et services externes.