Transports MCP : stdio, Streamable HTTP et SSE

Toute connexion MCP transporte les mêmes messages (requêtes, réponses et notifications JSON-RPC 2.0), mais ils peuvent circuler de différentes manières. La spécification les appelle des transports, et l’entrée d’un serveur dans le registre indique ceux qu’il prend en charge.

Serveurs en Streamable HTTP
16 864
Serveurs en stdio (processus local)
13 123
Serveurs en SSE (HTTP + Server-Sent Events)
515

stdio : un programme sur votre ordinateur

Avec stdio, le client lance le serveur comme processus enfant sur le même ordinateur. Le client écrit les messages sur l’entrée standard du serveur et lit les réponses sur sa sortie standard, à raison d’un message JSON-RPC par ligne ; le serveur peut écrire des journaux sur la sortie d’erreur standard. Lorsque le client ferme la connexion, le processus se termine.

Rien n’écoute sur un port réseau, il n’y a donc pas d’URL à protéger - mais le programme s’exécute avec les droits de l’utilisateur et peut lire tout ce que celui-ci peut lire. Les serveurs stdio s’installent à partir de paquets : npm, PyPI, images de conteneur, MCP Bundles, entre autres.

Streamable HTTP : un seul point de terminaison sur le web

Introduit dans la révision 2025-03-26 de la spécification, Streamable HTTP utilise un unique point de terminaison HTTPS, comme https://example.com/mcp. Le client envoie chaque message par une requête HTTP POST. Le serveur répond soit par une réponse JSON unique, soit en ouvrant un flux Server-Sent Events, par lequel il peut envoyer plusieurs messages - des notifications de progression, par exemple - avant le résultat final. Le client peut aussi ouvrir un flux GET pour recevoir les messages que le serveur émet de sa propre initiative.

Un serveur peut attribuer une session, identifiée dans un en-tête Mcp-Session-Id que le client renvoie dans ses requêtes suivantes. Comme il s’agit de HTTPS ordinaire, ce transport fonctionne avec l’authentification standard - la spécification d’autorisation MCP s’appuie sur OAuth - et avec l’infrastructure web habituelle.

SSE : l’ancien transport HTTP

La première révision publiée (2024-11-05) définissait un transport HTTP fondé sur les Server-Sent Events : le client ouvre une connexion GET persistante pour le flux d’événements, le premier événement du serveur indique une seconde URL, et le client y envoie ses propres messages en POST. La révision 2025-03-26 l’a remplacé par Streamable HTTP ; clients et serveurs peuvent continuer à le prendre en charge par souci de rétrocompatibilité, ce qui explique que certains serveurs listent les deux.

Quel transport pour quel serveur

Un service hébergé auquel de nombreuses personnes accèdent depuis de nombreux assistants propose normalement Streamable HTTP, le transport que le protocole recommande désormais pour les serveurs distants. Un outil qui doit accéder à des fichiers ou à des applications locales utilise stdio. Un serveur peut proposer les deux : son entrée dans le registre liste alors un point de terminaison distant et un paquet, et sa page ici affiche chacun d’eux.

Serveurs MCP par transport · Distant ou local ? · Parcourir l’annuaire →

Voir aussi : Qu’est-ce qu’un serveur MCP ? · Qu’est-ce que le fichier llms.txt ? · Comment les assistants IA trouvent et réservent des voyages · Comment les fiches sont vérifiées · Serveur MCP distant ou local : lequel choisir · Comment ajouter un serveur MCP à un assistant IA · Qu’est-ce que le MCP Registry officiel ? · Que mettre dans un fichier llms.txt · OpenAPI pour les agents IA · Comment les assistants IA trouvent les disponibilités · Avant de connecter un serveur MCP : liste de vérification