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 n'êtes pas limité à 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 concret
Parcourons un exemple complet pour voir comment toutes ces pièces fonctionnent ensemble. Imaginez qu'un utilisateur demande « Quels dépôts ai-je ? » - voici l'ensemble de la chaîne de communication :
Le processus commence lorsqu'un utilisateur soumet sa question à votre serveur. Votre serveur se rend compte qu'il doit fournir à Claude les outils disponibles avant de faire la requête à l'IA.
Votre serveur demande au client MCP une liste d'outils, ce qui déclenche une ListToolsRequest vers le serveur MCP. Le serveur répond avec ListToolsResult contenant tous les outils disponibles.
Maintenant votre serveur dispose de tout ce qui est nécessaire pour faire la requête initiale à Claude : la question de l'utilisateur ainsi que les outils disponibles. Claude analyse les outils et décide qu'il doit en appeler un pour répondre correctement à la question.
Claude répond avec une demande d'utilisation d'outils. Votre serveur reconnaît cela et demande 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 alors l'appel API réel à GitHub pour récupérer les dépôts de l'utilisateur.
GitHub renvoie les données des dépôts, que le serveur MCP enveloppe dans un CallToolResult et renvoie à travers la chaîne. Votre serveur reçoit ces données et peut maintenant faire une requête de suivi à Claude.
La dernière étape envoie les résultats de l'outil à Claude dans le cadre d'un message utilisateur. Claude dispose maintenant de toutes les informations nécessaires pour formuler une réponse complète concernant les dépôts de l'utilisateur.
Oui, ce flux comporte de nombreuses étapes, mais le comprendre vous prépare à implémenter vos propres clients et serveurs MCP. Chaque composant a un rôle spécifique, et les types de messages standardisés garantissent que tout fonctionne ensemble harmonieusement, quel que soit le mécanisme de transport sous-jacent.