Clients MCP

Les serveurs MCP fournissent les outils ; le client MCP est la pièce qui les rend accessibles. Il sert de pont de communication entre votre application et les serveurs MCP — c’est votre point d’accès à tous les outils qu’un serveur fournit, et il vit dans votre code, aux côtés de la boucle de conversation avec Claude. Comprendre ce qu’il échange réellement avec le serveur, c’est comprendre la totalité de ce que MCP normalise.

Communication agnostique du transport

L’une des forces clés de MCP est d’être agnostique du transport : le client et le serveur peuvent communiquer via différentes méthodes sans que leur logique change d’une ligne. La configuration la plus courante — celle de notre projet — fait fonctionner les deux sur la même machine, communiquant via l’entrée/sortie standard : le client lance le serveur en sous-processus et dialogue par stdin/stdout. Mais MCP supporte aussi HTTP, WebSockets et d’autres protocoles réseau, ce qui permet de déployer le même serveur comme service distant partagé. Le protocole définit le contenu des échanges, jamais leur tuyau — vous choisissez le transport selon votre déploiement, pas selon votre code.

Types de messages

Et que contient l’échange, justement ? L’essentiel tient en deux paires requête/réponse :

Découverte, puis exécution : ce sont exactement les deux opérations que nous codions à la main dans la section tool use — la liste de schémas d’un côté, la fonction de routage de l’autre. MCP n’ajoute aucun concept : il fige le format de ces deux é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

Situons le client dans une exécution de bout en bout. Votre application est connectée à un serveur MCP GitHub, et un utilisateur demande « Quels repositories ai-je ? » :

1. L’utilisateur soumet sa question à votre serveur
2. Votre serveur demande au client MCP la liste des outils disponibles
3. Le client envoie un ListToolsRequest au serveur MCP et reçoit la liste
4. Votre serveur envoie à Claude la question + la liste des outils
5. Claude analyse et décide d’appeler un outil
6. Votre serveur demande au client MCP d’exécuter l’outil
7. Le client envoie un CallToolRequest au serveur MCP
8. Le serveur MCP appelle l’API GitHub et renvoie les données
9. Le client retransmet les résultats à votre serveur
10. Votre serveur envoie les résultats à Claude
11. Claude formule sa réponse finale

Onze étapes, mais regardez la répartition : les étapes 1, 4-6, 10-11 sont votre boucle de conversation habituelle — question, outils, tool_use, tool_result, réponse. Seules les étapes 2-3 et 7-9 impliquent MCP, et elles remplacent très exactement ce qui était auparavant local : la liste d’outils codée en dur, et le run_tool maison. Notez aussi qui est absent du protocole : Claude. Le modèle voit des outils et des résultats, comme toujours — il ignore tout de MCP, du transport et du serveur GitHub.

Ce flux implique beaucoup d’étapes, mais chaque composant a une responsabilité claire. Le client MCP abstrait la complexité de la communication avec le serveur, vous laissant vous concentrer sur la logique de votre application — et c’est précisément lui que nous implémenterons dans les prochaines leçons, méthode par méthode.

Points clés à retenir

• Le client MCP vit dans votre application : point d’accès unique aux outils d’un serveur
• Transport agnostique : stdio en local, HTTP/WebSockets en distant — la logique ne change pas
• Deux paires de messages suffisent : ListTools (découverte) et CallTool (exécution)
• Dans le flux complet, MCP ne remplace que la provenance des outils — la boucle de conversation reste la vôtre
• Claude ignore l’existence du protocole : il voit des outils et des résultats, rien de plus