Les clients MCP

Les serveurs MCP fournissent les capacités ; le client MCP est la pièce qui y donne accès. C’est le pont de communication entre votre application et les serveurs MCP — pensez-y comme votre point d’accès à tous les outils qu’un serveur fournit. Il gère tous les détails du protocole et du passage de messages pour vous : comprendre ce qu’il échange, c’est comprendre tout ce que MCP normalise réellement.

Indépendance du transport

L’un des points forts de MCP est d’être agnostique au transport — le client et le serveur peuvent communiquer via différentes méthodes sans qu’une ligne de leur logique ne change. La configuration la plus courante fait tourner les deux sur la même machine et communique via l’entrée/sortie standard (stdio) : le client lance le serveur en sous-processus, lui écrit sur stdin, le lit sur stdout — c’est le montage de notre projet.

Mais vous n’êtes pas limité à cette approche. Les clients et serveurs MCP peuvent aussi se connecter via :

• HTTP
• WebSockets
• D’autres protocoles réseau

La conséquence pratique : un serveur développé en stdio local peut devenir un service réseau partagé sans réécriture — le protocole définit ce qui se dit, jamais par où ça passe.

Types de messages

Et que se disent-ils ? Une fois connectés, le client et le serveur échangent des types de messages définis dans la spécification MCP — et l’essentiel tient en deux paires :

Découverte, puis exécution : vous reconnaissez les deux opérations que vous implémentiez localement — la liste de schémas d’un côté, la fonction d’exécution de l’autre. MCP n’invente aucun concept : il fige le format de ces échanges pour que n’importe quel client comprenne n’importe quel serveur, quels que soient leurs auteurs. C’est cette poignée de messages standardisés qui fait exister l’écosystème.

Flux complet

Voici comment tout s’articule dans un exemple concret : votre application est connectée à un serveur MCP GitHub, et un utilisateur pose la question « Quels dépôts ai-je ? »

1. L'utilisateur soumet sa requête à votre serveur
2. Votre serveur demande la liste des outils disponibles au client MCP
3. Le client envoie ListToolsRequest → reçoit ListToolsResult
4. Votre serveur fait la requête initiale à Claude avec les outils disponibles
5. Claude décide d'utiliser un outil et répond avec une demande d'appel d'outil
6. Votre serveur demande au client MCP d'exécuter cet outil
7. Le client envoie CallToolRequest → le serveur MCP appelle l'API GitHub
8. GitHub retourne les données → CallToolResult → client → votre serveur
9. Votre serveur renvoie les résultats à Claude
10. Claude formule sa réponse finale

Dix étapes, mais regardez la répartition : les étapes 1, 4-6 et 9-10 sont votre boucle de conversation avec outils, strictement inchangée. Seules les étapes 2-3 et 7-8 impliquent MCP — et elles remplacent très exactement ce qui était local : la liste d’outils codée en dur et le run_tool maison. Quant à Claude, il est absent du protocole : il voit des outils et des résultats, comme toujours — il ignore que MCP existe.

À retenir : Vous n’avez pas à gérer les détails du protocole. Le client MCP s’en charge, et vous appelez simplement list_tools() et call_tool().

Ces deux méthodes sont précisément celles que nous implémenterons dans quelques leçons — après avoir construit le serveur qu’elles interrogeront.

Points clés à retenir

• Le client MCP vit dans votre application : point d’accès unique aux capacités d’un serveur
• Transport agnostique : stdio en local (notre projet), HTTP/WebSockets en distant — même logique
• Deux paires de messages portent l’essentiel : ListTools (découverte) et CallTool (exécution)
• Dans le flux complet, MCP ne remplace que la provenance des outils — votre boucle reste intacte
• Claude ignore le protocole : des outils, des résultats — rien de nouveau pour le modèle