Les clients MCP

Le serveur MCP expose des outils ; encore faut-il quelqu’un pour lui parler. C’est le rôle du client MCP : le pont de communication entre votre application et les serveurs MCP. Il vit à l’intérieur de votre code — dans l’application qui héberge la conversation avec Claude — et traduit les besoins de celle-ci en messages du protocole. Comprendre ce que le client échange avec le serveur, c’est comprendre tout ce que MCP standardise réellement.

Communication agnostique au transport

Première propriété du protocole : MCP est agnostique au transport. Client et serveur peuvent communiquer par différents canaux sans qu’une ligne de leur logique ne change. Le cas le plus courant en développement : les deux tournent sur la même machine et échangent via l’entrée/sortie standard — le client lance le serveur comme un sous-processus et lui écrit sur stdin, lit sur stdout. Mais le même protocole passe aussi par HTTP, WebSockets et d’autres canaux réseau, ce qui permet de déployer un serveur MCP comme service distant partagé par plusieurs applications. Cette indépendance est un choix de conception délibéré : le protocole définit ce qui se dit, jamais par où ça passe.

Types de messages

Que se disent-ils, justement ? L’essentiel du dialogue tient en deux paires de messages :

• ListToolsRequest/ListToolsResult : le client demande « quels outils as-tu ? » et reçoit la liste complète
• CallToolRequest/CallToolResult : le client dit « exécute cet outil avec ces arguments » et reçoit les résultats

Vous reconnaissez la structure : c’est exactement le duo découverte/exécution que nous implémentions localement avec une liste de schémas et une fonction run_tool. MCP n’invente pas de nouveau concept — il standardise ces deux opérations pour qu’elles fonctionnent entre n’importe quel client et n’importe quel serveur, quel que soit leur auteur. C’est cette normalisation qui crée l’écosystème : un serveur écrit une fois est utilisable par tous les clients compatibles.

Flux complet d’un exemple réel

Déroulons la chaîne entière sur un cas concret : votre application est connectée à un serveur MCP GitHub, et un utilisateur demande « Quels dépôts ai-je ? ».

1. L’utilisateur soumet sa question à votre serveur
2. Votre serveur demande la liste des outils au client MCP
3. Le client MCP envoie un ListToolsRequest au serveur MCP
4. Le serveur MCP répond avec les outils disponibles
5. Votre serveur envoie la question + les outils à Claude
6. Claude répond avec une demande d’outil (tool_use)
7. Votre serveur demande au client MCP d’exécuter l’outil
8. Le client MCP envoie un CallToolRequest au serveur MCP
9. Le serveur MCP appelle l’API GitHub
10. Les données remontent la chaîne jusqu’à votre serveur
11. Vous envoyez les résultats à Claude
12. Claude formule la réponse finale

Douze étapes, mais regardez qui fait quoi : les étapes 1-2, 5-7 et 11-12 sont la boucle de conversation avec outils que vous savez déjà écrire — rien de nouveau. Les étapes 3-4 et 8-10 sont les seules où MCP intervient, et elles remplacent précisément ce qui était auparavant du code local : la liste d’outils codée en dur et la fonction d’exécution. Claude, lui, ne sait même pas que MCP existe — il voit des outils et des résultats, comme toujours. Le protocole est une affaire de plomberie entre votre application et les sources d’outils, invisible pour le modèle comme pour l’utilisateur.

Points clés à retenir

• Le client MCP vit dans votre application : c’est le pont entre elle et les serveurs MCP
• Agnostique au transport : stdio en local, HTTP ou WebSockets en distant — même protocole
• 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 — la boucle de conversation est inchangée
• Claude ignore l’existence de MCP : il voit des outils et des résultats, comme avec des fonctions locales