Les clients et serveurs MCP communiquent en échangeant des messages JSON, mais comment ces messages sont-ils réellement transmis ? Le canal de communication utilisé s'appelle un transport, et il existe plusieurs façons de l'implémenter - des requêtes HTTP aux WebSockets, en passant même par l'écriture de JSON sur une carte postale (bien que cette dernière option ne soit pas recommandée pour une utilisation en production).
Le transport Stdio
Lorsque vous développez pour la première fois un serveur ou un client MCP, le transport le plus couramment utilisé est le transport stdio. Cette approche est simple : le client lance le serveur MCP en tant que sous-processus et communique via les flux d'entrée et de sortie standard.
Voici comment cela fonctionne :
- Le client envoie des messages au serveur en utilisant le
stdindu serveur - Le serveur répond en écrivant sur
stdout - Le serveur ou le client peut envoyer un message à tout moment
- Cela ne fonctionne que lorsque le client et le serveur s'exécutent sur la même machine
Observer Stdio en action
Vous pouvez en fait tester un serveur MCP directement depuis votre terminal sans écrire de client séparé. Lorsque vous exécutez un serveur avec uv run server.py, celui-ci écoute l'entrée standard et écrit les réponses sur la sortie standard. Cela signifie que vous pouvez coller des messages JSON directement dans votre terminal et voir immédiatement les réponses du serveur.
La sortie du terminal affiche l'échange complet de messages, y compris des exemples de messages pour l'initialisation et les appels d'outils.
Séquence de connexion MCP
Chaque connexion MCP doit commencer par une poignée de main spécifique en trois messages :
- Requête d'initialisation (Initialize Request) - Le client l'envoie en premier
- Résultat d'initialisation (Initialize Result) - Le serveur répond avec ses capacités
- Notification d'initialisation (Initialized Notification) - Le client confirme (aucune réponse n'est attendue)
Ce n'est qu'après cette poignée de main que vous pouvez envoyer d'autres requêtes, comme des appels d'outils ou des listes de requêtes.
Types de messages et flux
MCP prend en charge divers types de messages qui circulent dans les deux sens :
L'idée clé est que certains messages nécessitent des réponses (requêtes → résultats) tandis que d'autres non (notifications). Le client et le serveur peuvent tous deux initier la communication à tout moment.
Quatre scénarios de communication
Avec n'importe quel transport, vous devez gérer quatre schémas de communication différents :
- Requête Client → Serveur : Le client écrit sur stdin
- Réponse Serveur → Client : Le serveur écrit sur stdout
- Requête Serveur → Client : Le serveur écrit sur stdout
- Réponse Client → Serveur : Le client écrit sur stdin
La beauté du transport stdio réside dans sa simplicité - chaque partie peut initier la communication à tout moment en utilisant ces deux canaux.
Pourquoi cela est important
Comprendre le transport stdio est essentiel, car il représente le cas « idéal » où la communication bidirectionnelle se déroule sans accroc. Lorsque nous passerons à d'autres transports comme HTTP, nous rencontrerons des limitations où le serveur ne peut pas toujours initier des requêtes vers le client. Le transport stdio sert de référence pour comprendre à quoi ressemble une communication MCP complète avant d'aborder les contraintes des autres méthodes de transport.
Pour le développement et les tests, le transport stdio est parfait. Pour les déploiements en production où le client et le serveur doivent s'exécuter sur des machines différentes, vous devrez envisager d'autres options de transport, chacune avec ses propres compromis.