Introduction
Depuis son lancement, le Model Context Protocol souffrait d'une contrainte structurelle bien connue des équipes qui avaient tenté de le déployer à grande échelle : son architecture stateful imposait de maintenir des sessions persistantes entre le client et le serveur. Exit le round-robin classique, exit le serverless, exit les déploiements edge — chaque connexion devait rester collée à la même instance. La mise à l'échelle horizontale, triviale pour n'importe quelle API REST, devenait un problème d'architecture à part entière.
La spécification publiée le 28 juillet 2026 referme ce dossier. Il s'agit de la cinquième révision du protocole, et de loin la plus profonde depuis son lancement.
Un protocole enfin sans état
Le changement central est architectural : MCP abandonne son modèle bidirectionnel à sessions pour adopter une approche request/response sans état. Chaque requête devient auto-descriptive — elle porte avec elle la version du protocole et les capacités du client dans ses métadonnées. L'en-tête Mcp-Session-Id disparaît. Le handshake initialize/initialized est retiré de la spécification.
Pour les équipes DevOps, la conséquence est immédiate : un serveur MCP peut maintenant fonctionner derrière n'importe quelle infrastructure HTTP standard — load balancer round-robin, fonctions serverless, nœuds edge. Plus de sessions collantes, plus d'état partagé entre instances. La montée en charge redevient aussi simple que pour un microservice sans état ordinaire.
Pour les interactions qui nécessitent encore plusieurs allers-retours — collecte d'entrées supplémentaires, validation progressive — la spec introduit les Multi Round-Trip Requests : le serveur signale qu'une réponse est incomplète sans maintenir de connexion persistante ouverte, ce qui préserve la compatibilité avec les infrastructures stateless.
Un cadre d'extensions officiel
Au-delà de l'architecture réseau, la spec 2026-07-28 instaure un framework officiel pour étendre le protocole sans toucher à son cœur. Deux extensions inaugurent ce cadre. Tasks — gestion de travaux asynchrones de longue durée — sort du statut expérimental pour devenir l'extension io.modelcontextprotocol/tasks, dotée d'un mécanisme de poll (tasks/get) et de mise à jour (tasks/update). MCP Apps permet d'intégrer des interfaces utilisateur directement dans les flux MCP. Une troisième extension, Enterprise Managed Authorization, cible les déploiements en contexte d'entreprise avec des exigences d'identité strictes.
OAuth 2.0 et OIDC renforcés
Sur le terrain de l'authentification, la spec renforce son alignement sur OAuth 2.0 et OpenID Connect. La validation de l'issuer selon la RFC 9207 devient obligatoire. Le Dynamic Client Registration est déprécié au profit des Client ID Metadata Documents, une approche mieux adaptée aux déploiements enterprise connectés à des systèmes d'identité comme Microsoft Entra ou Okta.
Les quatre SDK Tier 1 en ordre de marche
Les SDK TypeScript, Python, Go et C# sortent simultanément avec le support complet de la spécification 2026-07-28. Un cinquième SDK, en Rust, est disponible en bêta. Côté dépréciations, les capacités Roots, Sampling et Logging bénéficient d'une période de transition d'au moins douze mois. Le transport HTTP+SSE hérité a lui aussi un an pour laisser place à la nouvelle architecture.
Ce qu'il faut anticiper maintenant
Pour les équipes qui maintiennent des serveurs MCP en production, cette version est une rupture bénéfique mais qui demande un audit. Le handshake de session disparaît, le transport SSE est déprécié, certaines capacités core changent de statut. La fenêtre de douze mois est généreuse — mais l'inventaire vaut mieux être fait tôt que tard, avant que les dépendances ne se cristallisent autour de comportements qui seront bientôt supprimés.