Model Context Protocol (MCP), dans sa version 2026-07-28, est devenu un protocole entièrement sans état, après la réécriture de son cœur, de son modèle d’interaction et des packages SDK associés. Cloudflare affirme que ce changement permet d’exécuter des serveurs MCP dans un Worker ordinaire, sans infrastructure dédiée au maintien des sessions du protocole, tout en réduisant la complexité opérationnelle et les coûts liés aux composants supplémentaires.
La nouvelle spécification a été publiée la semaine dernière, en même temps que des versions mises à jour des packages SDK pour TypeScript, Python, Go et C#. Selon Cloudflare, les serveurs peuvent désormais recevoir une requête, exécuter un outil, une invite ou une ressource, puis renvoyer le résultat sans stocker de session de protocole entre les requêtes.
Abandon des sessions obligatoires
Les versions précédentes commençaient par un échange initialize et initialized pour créer une session, avec la possibilité d’attribuer un identifiant via l’en-tête Mcp-Session-Id. Chaque requête ultérieure devait accéder à l’état associé à cette session, ce qui posait des difficultés aux environnements reposant sur la mise à l’échelle automatique et obligeait les déploiements à drainer ou à transférer les sessions actives. La perte d’une instance active du serveur pouvait entraîner la reconnexion du client ou l’interruption de la session.
La nouvelle version supprime la négociation obligatoire, l’en-tête Mcp-Session-Id et les sessions du chemin de requête principal. Chaque requête contient la version du protocole, l’identité du client et les capacités nécessaires. L’appel à server/discover pour inspecter le serveur avant d’exécuter une autre requête devient facultatif.
Cela ne signifie pas que les applications avec état ne sont plus nécessaires : Cloudflare précise que Durable Objects restent adaptés lorsque l’application elle-même a besoin d’un état coordonné. Cependant, MCP ne nécessite plus Durable Objects pour communiquer via le protocole, et les serveurs qui ont besoin d’un traitement lié à la requête peuvent évoluer sur Workers.
Des interactions en plusieurs étapes plutôt qu’un streaming ouvert
La version repense le mécanisme d’elicitation, utilisé lorsque le serveur a besoin d’informations supplémentaires avant de terminer la requête, par exemple d’une autorisation pour déployer une version en production ou d’une confirmation concernant le montant d’un remboursement. Auparavant, les requêtes initiées par le serveur reposaient sur un streaming ouvert.
Avec le mécanisme Multi Round-Trip Requests, le serveur peut renvoyer un résultat nommé input_required indiquant les données nécessaires. Le client recueille la réponse, puis réessaie l’opération avec ces données, sans qu’aucune partie ne conserve de session de transport entre les deux requêtes. Cloudflare décrit ce changement comme incompatible avec l’ancien modèle, mais plus simple sur le plan opérationnel.
Rendre les requêtes MCP compréhensibles pour l’infrastructure HTTP
La nouvelle spécification exige les deux en-têtes Mcp-Method et Mcp-Name dans les requêtes Streamable HTTP. Ainsi, la passerelle, le limiteur de débit ou le pare-feu applicatif peut savoir si la requête appelle un outil ou lit une ressource, sans analyser entièrement le contenu JSON-RPC.
La spécification ajoute également les indications ttlMs et cacheScope aux résultats de tools/list, prompts/list, resources/list et resources/read, ainsi qu’un ordre déterministe pour les index d’outils, ce qui permet leur réutilisation et préserve la stabilité du cache des invites lors d’une reconnexion.
Changements concernant l’autorisation et le cycle de vie des fonctionnalités
La nouvelle spécification privilégie les clients préenregistrés lorsqu’une relation existe déjà entre le client et le serveur, puis utilise les documents de métadonnées client CIMD pour l’enregistrement dynamique, tandis que Dynamic Client Registration, ou DCR, devient une solution de secours. DCR est désormais déclaré obsolète pour les nouvelles applications et sa suppression est prévue après l’été 2027.
La spécification adopte également le mécanisme de la RFC 9207 pour l’identification de l’émetteur et impose l’utilisation de l’URL de base du serveur comme ressource, conformément à la RFC 8707, dans les requêtes d’autorisation et de jetons. Cloudflare affirme que Workers OAuth Provider applique ces exigences aux serveurs MCP sur Workers.
La spécification dispose désormais d’un cycle de vie officiel qui classe les fonctionnalités comme actives, obsolètes ou supprimées. Une fonctionnalité obsolète doit rester disponible pendant au moins 12 mois avant sa suppression. Les fonctionnalités déclarées obsolètes dans cette version comprennent Roots, Sampling, Logging, DCR et l’ancien mécanisme HTTP+SSE. MCP Apps et Enterprise-Managed Authorization deviennent des extensions, tandis que Tasks est transféré vers le cadre des extensions afin de fournir une voie pour les opérations longues et fiables.
Voie de migration et disponibilité
L’interface createMcpHandler sort de son statut expérimental pour rejoindre le package officiel MCP TypeScript SDK, et Cloudflare continue de fournir une interface destinée à Workers dans Agents SDK. L’entreprise a également contribué au portage du SDK TypeScript de Node.js vers les Web Standards afin d’améliorer sa compatibilité avec Bun, Deno et Cloudflare Workers.
Les clients peuvent migrer tout en conservant la compatibilité avec les spécifications antérieures. Le point de terminaison /mcp accepte le nouveau protocole et les requêtes sans état provenant de clients Streamable HTTP utilisant la version 2025, ce qui permet à la plupart des clients de se reconnecter sans modifier leur configuration. En revanche, les serveurs qui dépendent d’anciennes sessions, de requêtes du serveur vers le client ou de flux indépendants nécessitent une voie de migration plus prudente, par exemple en exécutant un chemin sans état à côté de l’ancien jusqu’à l’épuisement des sessions actives.
Cloudflare indique que la nouvelle spécification est disponible pour les clients et les serveurs sur sa plateforme, et qu’un serveur MCP sans état peut être exécuté sur un Worker et sécurisé via Workers OAuth Provider. Selon l’entreprise, son service Code Mode MCP Server pour l’API Cloudflare a utilisé cette approche et atteint des milliers de requêtes par seconde ainsi que des milliards d’appels d’outils.