Les clients MCP
Sur cette page
Le client MCP est le pont de communication entre votre serveur et les serveurs MCP. C’est votre point d’accès à tous les outils qu’un serveur MCP fournit : il gère l’échange de messages et les détails du protocole, pour que votre application n’ait jamais à s’en occuper. Vous appelez une méthode, il traduit en messages, il attend la réponse, il vous rend un objet Python. À la fin de cette leçon, vous saurez ce que signifie « agnostique au transport », quels messages circulent, et dans quel ordre une question traverse tout le système.
Communication agnostique au transport
L’un des points forts du MCP est d’être agnostique au transport. Le protocole décrit ce que client et serveur se disent, pas le tuyau par lequel ils se le disent — et ce découplage vous laisse choisir la configuration adaptée à votre déploiement.
La configuration la plus courante, celle que vous utiliserez dans cette section, fait tourner le client et le serveur sur la même machine, en communiquant par entrée/sortie standard (stdio). Le client lance le processus serveur et lui écrit sur son entrée standard, exactement comme deux programmes reliés par un pipe shell. C’est simple, rapide, et cela ne demande aucune configuration réseau. Mais rien ne vous y oblige : la spécification définit un second transport, Streamable HTTP (des requêtes HTTP POST, avec des événements envoyés par le serveur en option), pour les serveurs qui tournent ailleurs que sur la machine de l’utilisateur et servent plusieurs clients à la fois. Dans les deux cas, les messages sont les mêmes : du JSON-RPC 2.0, requêtes, réponses et notifications. L’ancien transport HTTP+SSE est déprécié depuis la version 2026-07-28.
Types de messages MCP
Une fois la connexion établie, le client et le serveur échangent des types de messages définis par la spécification MCP. Deux paires suffisent à couvrir tout le cycle de vie d’un outil : découvrir ce qui existe, puis exécuter ce qu’on a choisi.
| Message | Description |
|---|---|
ListToolsRequest / ListToolsResult | Le client demande : “quels outils tu fournis ?” et reçoit la liste |
CallToolRequest / CallToolResult | Le client demande l’exécution d’un outil avec des arguments et reçoit le résultat |
Remarquez la symétrie du nommage : à chaque requête correspond un résultat portant le même préfixe. Sur le fil, ces messages s’appellent tools/list et tools/call ; vous retrouverez cette convention pour les ressources (resources/list, resources/read) et les prompts (prompts/list, prompts/get) dans les leçons suivantes, ce qui rend la spécification très prévisible une fois les deux premiers messages compris. Depuis la version 2026-07-28, chaque requête porte aussi la version du protocole et les capacités du client dans son champ _meta, et un appel server/discover permet d’interroger les versions et capacités du serveur ; les versions antérieures passaient par une poignée de main initialize au début de la connexion, que vous verrez encore dans l’inspecteur.
Comment tout s’assemble
Suivons maintenant une requête complète, depuis la question de l’utilisateur jusqu’à la réponse de Claude. Un utilisateur demande : « Quels dépôts est-ce que j’ai ? »
Deux moments méritent d’être soulignés dans cette séquence. D’abord l’étape 3 : Claude ne découvre pas les outils tout seul ; c’est votre application qui les lui présente avec la question, et Claude choisit l’outil et ses arguments. Ensuite l’étape 4 : Claude n’exécute rien ; c’est votre code qui déclenche l’appel, par le client MCP. Le modèle décide, votre application agit.
Responsabilités claires
Oui, ce flux comporte de nombreuses étapes, et il peut sembler intimidant à la première lecture. Mais chaque composant a une responsabilité bien délimitée, et c’est précisément ce qui rend l’ensemble maintenable. Le client MCP abstrait la complexité de la communication avec le serveur, votre code se concentre sur la logique applicative, et le serveur MCP gère l’intégration avec les services externes. Aucune de ces trois briques n’a besoin de connaître le détail des deux autres.
Prenez le temps de vous approprier ce schéma : vous verrez toutes ces pièces en action, une par une, lorsque vous construirez vos propres serveurs et clients MCP dans les sections suivantes.
À vous de jouer
- Sans regarder le schéma, réécrivez les onze étapes du trajet d’une question, puis comparez. Les deux étapes où l’on se trompe le plus sont la 4 (qui présente les outils à Claude ?) et la 6 (qui exécute l’outil ?).
- Pour le service choisi à la leçon 49, choisissez le transport : le serveur tournera-t-il sur le poste de l’utilisateur (stdio) ou sur une machine partagée (Streamable HTTP) ? Justifiez en une phrase.
- Ouvrez un fichier de configuration MCP existant (celui de Claude Desktop ou de Claude Code) et identifiez la commande qui lance chaque serveur : c’est exactement ce que fait un client stdio.
Sources officielles : MCP clients (Claude Academy) · Aperçu de l’architecture : couches données et transport · Transports (spécification 2026-07-28)
Points clés à retenir
- Le client MCP est le pont entre votre application et les serveurs MCP ; il absorbe le protocole pour que votre code n’ait qu’à appeler des méthodes.
- Deux transports, mêmes messages JSON-RPC 2.0 : stdio sur la même machine, Streamable HTTP à distance ; HTTP+SSE est déprécié.
- Découvrir puis exécuter :
tools/listettools/call, et la même convention pour les ressources et les prompts. - Dans le trajet d’une question, votre application présente les outils à Claude, Claude choisit, votre code exécute.