MCP a son premier vrai breaking change : fin des sessions, place au stateless

Le protocole qui ne cassait jamais rien vient de casser quelque chose

Depuis qu'Anthropic a introduit le Model Context Protocol, MCP a traversé plusieurs révisions de spec sans jamais retirer quelque chose dont un serveur en production dépendait. Cette série s'est arrêtée le 28 juillet : la révision 2026-07-28 apporte le plus gros lot de changements depuis le lancement du protocole — et le premier qui casse vraiment le contrat entre client et serveur.

Le changement de fond : MCP n'est plus un protocole à sessions. Il devient stateless, requête par requête. Si vous avez déployé des serveurs MCP en supposant qu'une connexion vivante porte l'identité d'un appel à l'autre, cette hypothèse cesse d'être sûre sous la nouvelle spec — avec une fenêtre de dépréciation d'au moins douze mois, donc pas une urgence, mais un vrai chantier.

Ce qui change vraiment : plus de sessions, plus de handshake

Trois suppressions font le gros du travail. D'abord, les sessions au niveau protocole disparaissent — le header Mcp-Session-Id sort du transport Streamable HTTP, et tools/list/resources/list/prompts/list ne varient plus par connexion. Un serveur qui a besoin d'état inter-appels génère désormais son propre handle et le repasse comme un argument d'outil ordinaire, exactement comme le ferait n'importe quelle API HTTP stateless. Ça inverse l'endroit où vit l'état :

// avant : l'état voyageait sur la connexion
initialize → Mcp-Session-Id: abc123 → tools/call   (session implicite)

// après : l'état est un argument explicite, généré par le serveur
tools/call { cursor: "srv_7f3a…" } → tools/call { cursor: "srv_9b1c…" }

Ensuite, le handshake initialize/notifications/initialized disparaît aussi. Chaque requête porte désormais sa propre version de protocole et ses capacités dans _meta (io.modelcontextprotocol/protocolVersion, io.modelcontextprotocol/clientCapabilities), et une nouvelle RPC server/discover — que les serveurs doivent implémenter — permet à un client de connaître les versions supportées et l'identité d'un serveur en amont, ou de s'en servir comme sonde de rétrocompatibilité. Un décalage de version renvoie maintenant un UnsupportedProtocolVersionError explicite au lieu d'un handshake qui échoue en silence. Il n'y a plus de « se connecter, puis parler » : chaque requête se décrit elle-même.

Enfin, la reprise de flux SSE disparaît. Perdez un flux de réponse en cours de requête sous la nouvelle spec et vous ne le récupérez plus via Last-Event-ID — vous rejouez toute la requête avec un nouvel ID. Combiné au stateless, c'est une vraie simplification pour qui fait tourner des serveurs MCP derrière un load balancer : plus d'affinité de session, plus de routing sticky, plus de problème « quel pod porte l'état de cette connexion ». Le stateless par défaut colle bien mieux au serverless et à l'edge que le design orienté connexion que MCP avait au lancement.

Les dépréciations : Sampling, Roots et Logging sont sur l'horloge

Le changement le plus discret compte pourtant plus pour qui a des serveurs en prod aujourd'hui : Roots, Sampling et Logging sont désormais formellement dépréciés, remplacés par un pattern « Multi Round-Trip Requests » (MRTR) pour tout ce qui était auparavant une requête initiée par le serveur.

Il vaut la peine de voir par quoi MRTR remplace vraiment le canal inverse, parce que « multi round-trip » sonne plus vague que ça ne l'est. Au lieu que le serveur rappelle le client en cours de requête, le serveur renvoie un InputRequiredResult dont le champ inputRequests liste exactement ce dont il a besoin ; le client rejoue la requête d'origine avec inputResponses attaché. Une seule forme de requête, aucun callback serveur-vers-client, aucun état à moitié ouvert à raisonner. Tout ce qui était roots/list, sampling/createMessage ou elicitation/create passe désormais par cette unique boucle de retry.

Les features dépréciées fonctionnent encore pendant la fenêtre, mais les nouvelles implémentations ne doivent plus s'appuyer dessus — et la spec est explicite sur la migration : passer les répertoires via des paramètres d'outil plutôt que Roots, appeler directement votre propre API fournisseur LLM plutôt que Sampling, logger vers stderr ou OpenTelemetry plutôt que la feature Logging.

Sampling mérite qu'on s'y arrête. Elle permettait à un serveur MCP de demander au LLM du client de faire une partie du raisonnement à sa place — pas de clé API séparée, pas de facture séparée, une intelligence empruntée à qui pilote le client. Ce confort disparaît. Chaque serveur qui s'appuyait dessus possède désormais ses propres appels modèle, ses propres clés fournisseur, sa propre ligne de coût. C'est un modèle de confiance moins élégant, mais plus honnête : celui qui fait le raisonnement est celui qui le paie et choisit quel modèle tourne.

Le SDK de référence a déjà livré la v2 — le jour même

Ce n'est pas une spec sur papier qui attend son adoption. Le SDK TypeScript @modelcontextprotocol a publié toute une famille de paquets v2.0.0 — core, server, client, plus des adaptateurs pour Express, Fastify, Hono et Node — le 27 juillet, quelques heures avant que la spec ne soit finalisée. Il y a aussi un paquet codemod qui réécrit automatiquement les imports d'une base v1, et un paquet server-legacy pour les équipes qui doivent continuer à servir des clients pré-2026-07-28 pendant leur migration.

Les frictions d'interop du début sont déjà documentées et déjà corrigées : les notes de release v2.0.0 du SDK décrivent une bêta qui rejetait à tort le DiscoverResult d'un serveur pourtant conforme — un écart avec le texte final de la spec qui provoquait de vrais échecs de connexion face à d'autres implémentations précoces, dont un SDK Go en pré-release. C'est le coût normal d'une spec qui atterrit simultanément sur plusieurs SDK officiels, et c'est plutôt bon signe : l'écosystème teste vraiment l'interop au lieu que chaque langage livre isolément.

Pour qui fait tourner des serveurs MCP en TypeScript, le parcours de migration est étonnamment complet pour une spec vieille d'une semaine : lire docs/migration/upgrade-to-v2.md, lancer le codemod, garder server-legacy devant les clients qu'on ne peut pas forcer à migrer tout de suite.

Ce qu'il faut vérifier cette semaine

Pas besoin de migrer aujourd'hui — la fenêtre de dépréciation est d'au moins douze mois, et la plupart des clients MCP hébergés continueront à négocier l'ancien handshake encore un moment. Mais trois vérifications sont peu coûteuses et valent d'être faites maintenant, avant que ça ne devienne un sujet d'urgence :

1. Grep vos serveurs MCP à la recherche d'un usage de Sampling. Si un serveur rappelle le LLM du client au lieu du sien, c'est la pièce avec une vraie implication de coût une fois la feature retirée — il vous faudra une clé fournisseur et une ligne de budget qui n'existent pas aujourd'hui.
2. Vérifiez si un élément de votre infra dépend de l'affinité de session pour le trafic MCP. Si un load balancer route par Mcp-Session-Id aujourd'hui, cette règle de routing devient du poids mort une fois les serveurs passés au modèle stateless — mieux vaut le signaler avant que quelqu'un ne passe un sprint à débugger une « connexion » qui n'existe plus.
3. Si vous êtes sur le SDK TypeScript, lancez le codemod sur une branche dès maintenant, même sans merger. Les bugs d'interop déjà repérés par l'équipe SDK (le décalage sur DiscoverResult face aux premières implémentations Go) sont exactement le genre de chose qu'on préfère rencontrer sur une branche plutôt qu'en prod dans trois mois, quand l'horloge de dépréciation sera plus bruyante.

Ce qu'on parie pour la semaine prochaine

On surveille deux choses. D'abord, si les SDK Python et Go livrent un support v2 équivalent au même rythme que le SDK TypeScript — une seule implémentation de référence rapide ne dit rien sur le fait que la spec fonctionne bien à travers les runtimes. Ensuite, si l'une des plateformes MCP hébergées de taille moyenne publie son propre calendrier de migration ; une fenêtre de dépréciation de douze mois est généreuse, mais « généreux » est aussi la façon dont les migrations glissent discrètement jusqu'au mois 11.

Si vous faites tourner des serveurs MCP qui s'appuient sur Sampling pour du raisonnement à coût nul, commencez à chiffrer ce que vous coûterait un appel direct à une API LLM à la place — ce chiffre comptera plus que la date de dépréciation.

Vous faites tourner des serveurs MCP en production et vous n'êtes pas sûr de ce que la spec stateless touche vraiment dans votre parc ? Discutons.