Le Model Context Protocol publie aujourd'hui sa révision 2026-07-28, et pour qui exploite un serveur MCP distant, l'essentiel tient en une phrase : le protocole n'a plus de sessions. La poignée de main initialize disparaît, l'en tête Mcp-Session-Id disparaît, et les informations de version et de capacités qui s'échangeaient une fois à l'ouverture voyagent désormais dans _meta à chaque requête. C'est cette seule décision qui sort le routage collant du schéma de déploiement. La même révision apporte MCP Apps, une extension Tasks reconstruite, six propositions d'autorisation, et la première politique de dépréciation formelle du protocole, qui met Roots, Sampling et Logging sur une horloge de douze mois.
The short answer
La révision du Model Context Protocol datée 2026-07-28 paraît aujourd'hui et remplace 2025-11-25 comme version courante. Elle supprime la poignée de main initialize et l'en tête Mcp-Session-Id, déplace la version du protocole et les capacités dans _meta à chaque requête, et impose les en têtes Mcp-Method et Mcp-Name sur le transport Streamable HTTP pour que les passerelles routent sans analyser les corps. Les réponses de liste gagnent ttlMs et cacheScope. MCP Apps arrive comme première extension officielle, Tasks est rebâti autour de poignées plutôt que d'objets liés à une session, et un cycle de vie formel donne à chaque dépréciation un plancher de douze mois.
La plupart des révisions de protocole ajoutent des choses. Celle ci est surtout intéressante par ce qu'elle retire, et ce qu'elle retire, c'est la session.
La poignée de main disparaît
Sous 2025-11-25, un client MCP ouvrait une connexion, envoyait initialize, recevait les capacités du serveur, envoyait initialized, et se mettait seulement ensuite au travail. Le serveur renvoyait un Mcp-Session-Id, et chaque requête suivante le transportait. C'est une conception parfaitement normale, et c'est celle qui rendait la montée en charge horizontale pénible, puisqu'une requête porteuse d'un identifiant de session doit atteindre l'instance qui connaît cette session.
Dans la révision 2026-07-28, la poignée de main n'existe pas. La version du protocole, les informations client et les capacités voyagent dans _meta à chaque requête. Plus d'en tête de session, plus de session au niveau du protocole.
La conséquence est énoncée telle quelle dans l'annonce de la spécification : n'importe quelle requête peut atterrir sur n'importe quelle instance. Un tourniquet suffit. Le magasin de sessions partagé dont un serveur déployé horizontalement avait besoin pour survivre à une requête tombée sur la mauvaise réplique n'a plus rien à stocker.
Nous rangeons cela dans la catégorie des changements qui paraissent minces dans un diff et redessinent tout un schéma de déploiement.
Ce que le transport exige désormais
Deux en têtes deviennent obligatoires sur le transport Streamable HTTP : Mcp-Method et Mcp-Name. Ils portent l'opération invoquée, ce qui permet à un répartiteur de charge, une passerelle ou un limiteur de débit de router et de compter sur l'opération sans ouvrir le corps de la requête. Les serveurs doivent rejeter les requêtes dont les en têtes contredisent le corps, pour qu'on ne puisse pas faire passer une opération sous une règle écrite pour une autre.
Les réponses de liste et les lectures de ressources reçoivent ttlMs et cacheScope, empruntés assez directement à la logique du Cache-Control de HTTP. Un client sait combien de temps une réponse tools/list reste valide et si elle est partageable entre utilisateurs. Maintenir un flux Server Sent Events ouvert pour apprendre qu'une liste a changé cesse d'être nécessaire.
Mis bout à bout, ces trois détails décrivent un serveur MCP qui se comporte comme un service HTTP ordinaire. C'est tout l'argument de la révision, et c'est pourquoi le projet parle du plus grand changement depuis le lancement.
MCP Apps et le nouveau Tasks
Deux extensions accompagnent le cœur. MCP Apps est la première officielle : elle permet à un serveur de rendre du HTML interactif dans une iframe cloisonnée côté client. Les outils déclarent leurs gabarits d'interface à l'avance, ce qui permet à un client de les précharger et à une relecture de sécurité de les examiner avant tout rendu. Chaque action de l'utilisateur dans cette interface repasse par le JSON-RPC normal, donc le chemin de consentement et d'audit est le même que pour un appel d'outil direct. Aucun canal parallèle.
Tasks a été retravaillé pour un monde sans sessions. Le serveur répond à tools/call par une poignée de tâche, et le client pilote le travail avec tasks/get, tasks/update et tasks/cancel. La création de tâche est dirigée par le serveur, selon la capacité annoncée par le client. Une victime au passage : tasks/list, retiré parce que lister des tâches suppose une portée dans laquelle lister, et que cette portée était la session. Qui utilisait l'API Tasks expérimentale de 2025-11-25 a du travail de migration ici, et c'est l'angle le plus vif de la révision.
La politique de dépréciation est la vraie bonne nouvelle
Pour la première fois, MCP dispose d'un cycle de vie écrit : Active, Deprecated, Removed, avec au moins douze mois entre le deuxième et le troisième. La dépréciation commence par une simple annotation, et la méthode continue de fonctionner.
Trois fonctions y entrent tout de suite. Roots laisse la place aux paramètres d'outil ou à la configuration. Sampling laisse la place à un dialogue direct avec un fournisseur de modèle. Logging laisse la place à stderr pour les serveurs stdio et à OpenTelemetry pour l'observabilité structurée.
Il existe une lecture de cette actualité qui n'y voit que de l'agitation. Nous la lisons autrement. Un protocole qui a grossi aussi vite avait besoin d'un moyen de se délester des morceaux qui doublonnaient l'écosystème autour de lui, et écrire les règles de retrait avant de s'en servir, c'est la différence entre une évolution et une casse.
À vérifier cette semaine
Commencez par l'état. Tout ce que votre serveur garde contre un identifiant de session doit trouver un nouveau logement, dans la requête ou dans un stockage dont vous choisissez la clé. Regardez ensuite ce dont votre déploiement n'a plus besoin : configuration collante sur le répartiteur, magasin de sessions partagé, règles de passerelle qui lisent les corps pour deviner la méthode appelée.
Vérifiez votre SDK avant d'écrire du code. La version candidate a été gelée le vingt et un mai et aujourd'hui est la date de publication, une fenêtre de dix semaines dimensionnée pour que les SDK de premier rang valident sur des charges réelles et livrent leur prise en charge. Les SDK bêta sont arrivés le vingt neuf juin. Au moment où nous écrivons, la page de versionnage de la spécification listait encore 2025-11-25 comme version courante, ce qui est typiquement le genre de bascule qui se fait dans les heures qui suivent une date de publication, pas avant.
Sources et pour aller plus loin
- La version candidate de la spécification MCP 2026-07-28
- Le blog du Model Context Protocol
- Versionnage et statut des révisions MCP
- Cycle de vie des fonctionnalités et politique de dépréciation
- Les notes de Microsoft sur la version candidate 2026-07-28
Questions fréquentes
La suppression des sessions casse t elle les serveurs écrits pour 2025-11-25 ?
Elle change la façon de les écrire, ce qui n'est pas la même chose qu'une casse du jour au lendemain. La négociation de version existe toujours, un serveur peut donc prendre en charge les deux révisions le temps que les clients suivent, et les fonctions dépréciées restent dans la spécification avec un plancher de douze mois avant de devenir éligibles au retrait. Ce qui doit vraiment être réécrit, c'est tout ce qui conservait un état par connexion entre l'appel initialize et les requêtes suivantes, puisque ce point d'ancrage n'existe plus. Si votre serveur stockait une identité, un répertoire de travail ou une liste d'outils activés contre un identifiant de session, cet état doit passer dans la requête ou dans un stockage que vous maîtrisez.
Qu'apportent concrètement Mcp-Method et Mcp-Name à l'exploitation ?
Du routage et de la limitation de débit sans lire le corps des requêtes. Auparavant, une passerelle qui voulait traiter tools/call autrement que tools/list devait analyser la charge JSON-RPC pour savoir ce qu'elle avait sous les yeux, ce qui coûte cher en bordure et se code mal. La nouvelle révision impose les deux en têtes sur le transport Streamable HTTP, si bien que nginx, Envoy ou une passerelle d'API peuvent filtrer sur un en tête comme pour n'importe quel service HTTP. Les serveurs doivent rejeter les requêtes dont les en têtes contredisent le corps, ce qui empêche l'en tête de devenir un mensonge exploitable.
Qu'est ce qui remplace le flux SSE permanent pour les changements de liste ?
Des métadonnées de cache. Les réponses de liste et les lectures de ressources portent maintenant ttlMs et cacheScope, calqués sur la logique du Cache-Control de HTTP. Un client met en cache tools/list aussi longtemps que le serveur l'autorise, et cacheScope lui indique si cette réponse est partageable entre utilisateurs ou propre à un seul. En pratique, un client n'a plus besoin de maintenir un flux ouvert dans le seul but d'apprendre qu'une liste a changé, ce qui était le point le plus pénible quand on héberge MCP derrière une infrastructure qui a des avis sur les connexions inactives.
Pourquoi déprécier Sampling et Logging ?
Dans les deux cas, MCP avait fait pousser une seconde version de quelque chose que l'écosystème autour faisait déjà bien. Sampling demandait au client de lancer une inférence pour le compte du serveur, et la consigne est désormais de s'intégrer directement à un fournisseur de modèle. Logging est remplacé par stderr pour les serveurs stdio et par OpenTelemetry pour l'observabilité structurée, ce vers quoi la plupart des exploitants renvoyaient déjà leurs serveurs MCP. Roots part aussi, au profit de paramètres d'outil ou de configuration. Dans les trois cas le remplaçant est banal et déjà présent dans votre pile, et c'est exactement l'idée.
Par quoi commencer si un serveur MCP tourne en production ?
Par l'inventaire de l'état. Notez chaque information que votre serveur associe aujourd'hui à une session, puis décidez pour chacune si elle appartient à la requête, à un jeton, ou à un stockage qui vous appartient. Regardez ensuite ce dont votre déploiement n'a plus besoin : le magasin de sessions partagé, la configuration collante du répartiteur de charge et toute règle de passerelle qui inspecte les corps peuvent en général disparaître, et c'est là que le gain d'exploitation se voit vraiment. La prise en charge par les SDK de premier rang était prévue dans la fenêtre de dix semaines entre le gel de la version candidate le vingt et un mai et aujourd'hui : vérifiez les notes de version de votre SDK avant de commencer.