Les clients MCP

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.

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 ce cours, 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 : vous pouvez tout aussi bien connecter les deux via HTTP, via des WebSockets, ou via d’autres protocoles réseau lorsque le serveur MCP tourne ailleurs que sur la machine de l’utilisateur.

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.

Remarquez la symétrie du nommage : à chaque requête correspond un résultat portant le même préfixe. Vous retrouverez cette convention pour les ressources et les prompts dans les leçons suivantes, ce qui rend la spécification très prévisible une fois les deux premiers messages compris.

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 ? »

1. Requête utilisateur
   └─► Votre serveur

2. Découverte des outils
   └─► Votre serveur demande les outils disponibles au client MCP

3. Échange ListTools
   └─► Client MCP → ListToolsRequest → Serveur MCP
   └─► Serveur MCP → ListToolsResult → Client MCP

4. Requête vers Claude
   └─► Votre serveur envoie la question + les outils disponibles à Claude

5. Décision d'appel d'outil
   └─► Claude décide d'appeler un outil

6. Exécution de l'outil
   └─► Votre serveur → Client MCP → CallToolRequest → Serveur MCP

7. Appel API externe
   └─► Serveur MCP → API GitHub

8. Retour des résultats
   └─► GitHub → Serveur MCP → CallToolResult → Client MCP

9. Résultat vers Claude
   └─► Votre serveur envoie les résultats à Claude

10. Réponse finale
    └─► Claude formule sa réponse → Utilisateur

Deux moments méritent d’être soulignés dans cette séquence. D’abord l’étape 4 : Claude ne découvre pas les outils tout seul, c’est votre serveur qui les lui présente avec la question. Ensuite l’étape 6 : Claude n’exécute rien, il indique quel outil appeler et avec quels arguments, et c’est votre code qui déclenche l’appel via 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.