MCP : stdio ou Streamable HTTP, quel transport ?

MCP (Model Context Protocol) définit deux transports standard. stdio : l'application lance le serveur comme un sous-processus sur la même machine et lui parle par l'entrée et la sortie standard. Streamable HTTP : le serveur tourne de façon indépendante, expose une seule adresse, et reçoit chaque message par une requête HTTP POST. En pratique : stdio pour un outil local, Streamable HTTP pour un service partagé ou hébergé. Règles lues dans la spécification 2026-07-28, le 15/11/2026.

Le tableau de choix

JSON-RPC est le format d'appel à distance utilisé par MCP ; SSE (Server-Sent Events) est un mécanisme HTTP qui permet au serveur d'envoyer plusieurs messages sur une même réponse.

stdio en détail

Le client lance le programme du serveur et échange avec lui des messages JSON-RPC, une ligne par message. La conséquence pratique, rappelée dans tous les tutoriels officiels : rien d'autre ne doit passer sur la sortie standard. Un print() en Python ou un console.log() en JavaScript corrompt les échanges. La journalisation va sur la sortie d'erreur (stderr).

Côté sécurité, la documentation conseille stdio aux serveurs prévus pour tourner en local : il limite l'accès au seul client qui a lancé le processus.

Streamable HTTP en détail

Ce que la spécification exige :

• Une seule adresse (l'« endpoint MCP »), qui accepte POST, par exemple https://example.com/mcp.
• Un POST par message. Le client annonce dans l'en-tête Accept qu'il accepte application/json et text/event-stream.
• Des en-têtes obligatoires qui recopient le corps du message, pour que répartiteurs de charge et passerelles puissent router sans lire le JSON :
  • MCP-Protocol-Version, par exemple 2026-07-28 ;
  • Mcp-Method, le nom de la méthode ;
  • Mcp-Name, le nom de l'outil, du prompt ou l'URI de la ressource, pour tools/call, resources/read et prompts/get. Si un en-tête ne correspond pas au corps, le serveur rejette la requête en 400 avec l'erreur HeaderMismatch (code -32020).
• La réponse est soit un objet JSON unique, soit un flux SSE limité à cette requête, qui peut porter des notifications de progression avant la réponse finale.
• Les notifications durables (liste d'outils modifiée, ressource mise à jour) passent par une requête subscriptions/listen dont la réponse reste ouverte.

Les trois règles de sécurité HTTP

1. Le serveur doit valider l'en-tête Origin de chaque connexion, contre les attaques par DNS rebinding (un site malveillant qui fait pointer son nom de domaine vers votre machine). Origine présente et invalide : réponse 403 Forbidden.
2. En local, le serveur devrait n'écouter que sur 127.0.0.1, pas sur toutes les interfaces (0.0.0.0).
3. Le serveur devrait authentifier toutes les connexions. Voir MCP distant et OAuth.

Ce qui a changé en 2026-07-28

Si vous avez écrit un serveur HTTP avant le 28/07/2026, plusieurs mécanismes ont disparu de la révision courante :

• plus de sessions de protocole ni d'en-tête Mcp-Session-Id ;
• plus de point d'entrée GET pour un flux séparé ;
• plus de reprise de flux par Last-Event-ID : un flux coupé perd la requête en cours, que le client doit renvoyer avec un nouvel identifiant ;
• le serveur n'envoie plus de requêtes de son côté : quand il a besoin d'une information, il renvoie un résultat « entrée requise » et le client relance la requête complétée.

Un serveur qui ne gère que cette révision devrait répondre 405 Method Not Allowed à un GET ou un DELETE, et ignorer un Mcp-Session-Id reçu. Détails sur la page ce qui change avec la version 2026-07-28.

Et l'ancien HTTP+SSE ?

Le transport HTTP+SSE de la version 2024-11-05 est déprécié depuis la version 2025-03-26. Les nouvelles implémentations ne devraient pas l'adopter. Certains clients le gardent pour compatibilité : Claude Code, par exemple, le signale comme déprécié et conseille HTTP quand il est disponible.

Transports personnalisés

La spécification autorise d'autres transports, à condition de garder le format JSON-RPC, les schémas d'échange et les métadonnées par requête. Sur un flux d'octets fiable (socket Unix, connexion réseau TCP), elle recommande de réutiliser le découpage de stdio, une ligne par message.