Le protocole MCP fait l'objet d'une mise à jour majeure : il devient complètement apatride et simplifie la communication HTTP

Points essentiels : MCP En introduisant un schéma de transport "streaming HTTP", le protocole parvient à une absence totale d'état et simplifie la communication, jetant ainsi les bases d'un plus large éventail d'applications futures.

Une proposition d'amélioration technique majeure du protocole Message Channel Protocol (MCP) a été approuvée, annonçant un avenir plus large pour ce protocole émergent. Au cœur de cette mise à jour se trouve une révolution dans la manière dont le MCP transfère les données, le rendant complètement sans état et simplifiant la communication avec le protocole HTTP normal.

 

Contexte : Limites de HTTP+SSE

Auparavant, le protocole MCP utilisait HTTP plus SSE (Server Sent Events) pour transférer les données. Cette approche présentait certaines limites :

• La déconnexion et la reconnexion ne sont pas prises en charge
• Les serveurs doivent maintenir des connexions longues pour assurer leur stabilité.
• Les messages du serveur ne peuvent être envoyés que par l'intermédiaire du SSE

Solutions innovantes : streaming HTTP

Pour résoudre ces problèmes, la communauté a proposé le schéma de transport "Streaming HTTP". Ce schéma contient les ajustements clés suivants :

• Éliminer l'interface /sse : tous les messages client-serveur sont transmis uniformément par l'interface /message (ou similaire).
• Escalade des demandes vers l'ESS : le serveur peut escalader une demande du client vers une connexion ESS pour obtenir des notifications ou des données push en temps réel.
• Gestion de l'identifiant de session : le client fournit un identifiant de session dans l'en-tête de la requête HTTP, que le serveur peut éventuellement utiliser pour identifier la session.
• Initier un flux ESS : Le client peut envoyer une requête GET vide à l'interface /message pour établir un flux ESS.

Ces améliorations permettent aux serveurs MCP d'être complètement sans état, ce qui élimine le besoin d'une connectivité constante et réduit considérablement la complexité du serveur et la consommation de ressources. En même temps, l'utilisation du protocole HTTP pur améliore la compatibilité de MCP, ce qui lui permet de mieux s'intégrer dans les infrastructures de réseau et les logiciels intermédiaires existants.

 

Réaction positive de la communauté

Cette proposition d'amélioration a été largement accueillie et a reçu des commentaires positifs de la part de la communauté MCP. shopify, Pydantic, Cloudflare, LangChain, Vercel, et Anthropique L'équipe et de nombreuses autres organisations et personnes y ont contribué.

 

Les multiples avantages de l'apatridie

L'apatridie est l'élément central de cette mise à jour du protocole MCP, et elle apporte de multiples avantages au MCP :

• Déploiement et maintenance simplifiés : il n'est pas nécessaire de gérer la persistance et la synchronisation des données de session, ce qui facilite le déploiement et l'extension du serveur.
• Amélioration de la stabilité du système : la défaillance d'un seul serveur n'affecte pas le fonctionnement global du système, ce qui permet d'atteindre plus facilement une haute disponibilité.
• Réduction de la consommation de ressources : il n'est plus nécessaire de maintenir des connexions longues et l'état des sessions, ce qui réduit l'utilisation des ressources du serveur et les coûts.

 

Scénario d'application

La mise en œuvre de MCP sans état ouvre de nouvelles possibilités pour de nombreux scénarios d'application :

• Serveur d'outils sans état : un serveur MCP totalement sans état peut être construit pour fournir uniquement les fonctionnalités de l'outil de modélisation linguistique sans gestion d'état, ce qui simplifie le processus d'invocation de l'outil.
• Serveurs sans état avec prise en charge des réponses en continu : même les serveurs sans état peuvent tirer parti de l'ESS pour fournir des réponses en continu, par exemple en transmettant des informations sur la progression en temps réel pendant l'exécution de l'outil.

 

Pourquoi le streaming HTTP sur WebSocket ?

WebSocket a également été envisagé dans la sélection du schéma de transport, mais la communauté a finalement choisi "Streaming HTTP" sur la base des considérations suivantes :

• Surcharge dans les scénarios RPC : pour les scénarios RPC (Remote Procedure Call) simples, l'utilisation forcée de WebSocket introduit une charge opérationnelle et de réseau inutile.
• Compatibilité avec les navigateurs : WebSocket n'est pas aussi souple que SSE en ce qui concerne les paramètres de l'en-tête de la requête HTTP et les implémentations de bibliothèques tierces dans l'environnement du navigateur.
• Complexité de la mise à niveau du protocole : WebSocket ne prend en charge que la mise à niveau des requêtes GET, le processus de mise à niveau des requêtes POST est complexe et augmente la latence.
• Spécification simplifiée du protocole : la spécification du protocole MCP tend à limiter la variété des protocoles de transport officiels afin d'éviter les problèmes de compatibilité.

 

Exploration de la sécurité

Si l'absence d'état présente de nombreux avantages, elle soulève également la question de la sécurité, notamment en ce qui concerne la gestion des identifiants de session et l'autorisation.

Certains développeurs ont souligné que si un serveur utilise l'en-tête de requête Mcp-Session-Id pour gérer les sessions, il devrait lier l'identifiant de session à l'environnement d'autorisation afin d'éviter qu'il ne soit utilisé à mauvais escient dans différents environnements d'autorisation. Cela signifie que l'identifiant de session doit être associé à un utilisateur ou à une session client spécifique, plutôt que d'être commun à tous.

Pour les développeurs à la recherche d'un serveur minimaliste, des mécanismes d'authentification complexes peuvent ne pas être applicables. En mode avec état, la requête HTTP elle-même peut être considérée comme la limite de la session. Toutefois, dans le modèle sans état, la question se pose toujours de savoir comment gérer la session de manière sécurisée sans cookies HTTP uniquement.

Certains développeurs suggèrent d'introduire des cookies HTTP uniquement pour gérer les sessions des clients, d'attribuer un identifiant unique à chaque session de client, puis de gérer plusieurs identifiants de session MCP sous cet identifiant afin de parvenir à une gestion hiérarchique des sessions, en tenant compte de la sécurité et de la flexibilité.

 

Résumé et perspectives

L'évolution du protocole MCP vers l'absence d'état est une étape importante vers la praticité et la facilité d'utilisation. L'adoption du schéma "Streaming HTTP" devrait abaisser le seuil de déploiement de MCP et attirer davantage de développeurs et de scénarios d'application. Bien qu'il y ait encore matière à discussion sur la sécurité, nous pensons qu'à mesure que la communauté continue à s'améliorer, l'avenir du protocole MCP vaut la peine d'être envisagé.

 

Propositions pertinentes

[RFC] Remplacer HTTP+SSE par le nouveau transport "Streamable HTTP" #206 Lien proposé : [RFC] Remplacer HTTP+SSE par le nouveau transport "Streamable HTTP" #206