The Model Context Protocol’s latest specification (2026-07-28) eliminates sessions entirely, making MCP a fully stateless protocol. Earlier proposals envisioned a default-stateless option with stateful sessions reserved for edge cases, but that dual-mode approach was rejected because it would have significantly increased protocol complexity, forcing clients and servers to maintain separate logic paths and expanding the potential for bugs. Plans to reintroduce sessions in alternative forms were also abandoned, as existing applications already implemented the session concept poorly. For those who still require sessions, the only path is to pin servers to the previous spec version (2025-11-25), which will be supported for at least 12 more months.

In the new stateless paradigm, each request is self-contained, enhancing elasticity and reliability. The old stateful model depended on an initial handshake to establish persistent state, binding a client session to a specific server instance. That prevented the use of simple stateless load balancers (e.g., L4/L7 round-robin) without adding complexity like session affinity. An instance failure meant complete state loss, obliging the client to detect the outage, reconnect, and redo the full negotiation—plus implementing lifecycle management logic on both sides. The stateless design unbundles operations that were previously handled in block during the handshake: protocol version negotiation and capability discovery now occur on a per-request basis via the `_meta` object and dedicated endpoints.

Moving to sessionless operation required reworking several adjacent components. Tasks, an alternative execution mode useful for batch operations that entered the protocol in the 2025-11-25 spec, now leaves the core and becomes an official extension. Application-level state management no longer uses sessions; instead, it relies on explicit identifiers generated by the server and passed as arguments. This shift raised issues that needed clarification, including the absence of a native mechanism to communicate identifier TTLs and the risk of orphaned state when context is compressed.

Another major addition is the Multi Round-Trip Request (MRTR) pattern, which lets servers signal that they need more information to process a request without requiring shared storage layers or stateful load balancing. In authorization—typically the most integration-intensive area—Dynamic Client Registration (DCR) is replaced by Client ID Metadata Documents (CIMD), though DCR support remains for backward compatibility. Client credentials are now bound to their issuer, prohibiting reuse across different authorization servers. All primary SDKs—TypeScript, Python, Go, and C#—support the new spec, with Rust support available in beta.

MCP est désormais un protocole sans état… et sans session. La dernière version de la spec (2026-07-28) entérine ce changement majeur.

Initialement, il était plutôt envisagé que MCP devienne stateless par défaut, avec le stateful en option de dernier ressort. Ce schéma de coexistence n’a pas été retenu, au motif qu’il aurait largement accru la complexité du protocole. Clients et serveurs auraient eu à maintenir des logiques séparées, avec une surface de bugs d’autant plus grande. Quant à l’idée de réintroduire les sessions sous une autre forme, elle a aussi été abandonnée… au motif que les applications existantes implémentaient déjà mal le concept.

Quiconque souhaite continuer à utiliser des sessions doit donc épingler son serveur MCP sur la version précédente de la spec (2025-11-25). Elle restera prise en charge encore au moins 12 mois.

Du sessionless au niveau protocole…

Dans le paradigme stateless, chaque requête est indépendante, interprétable de manière isolée. Cela favorise l’élasticité et la fiabilité. En tout cas par rapport au paradigme stateful.

Ce dernier implique un handshake initial qui établit un état persistant. Une session client étant liée à l’instance de serveur contenant cet état, il en découle l’impossibilité d’utiliser un load balancer stateless simple (type round-robin L4/L7). À moins d’implémenter des mécanismes qui ajoutent de la complexité, comme l’affinité de session.

Sur le sujet de la fiabilité, le modèle stateful implique qu’en cas de panne de l’instance serveur gérant une session, on perd l’état. Le client doit alors détecter la panne, réétablir une connexion et refaire toute la négociation.

L’approche stateful suppose aussi d’implémenter, côté client et serveur, une logique de gestion de cycle de vie.

Le modèle stateless est censé abaisser ces barrières à l’entrée. Il dégroupe des opérations jusque-là gérées en bloc lors du handshake. En particulier, la négociation de version de protocole et la découverte de capacités. Elles se font désormais au niveau des requêtes, à travers l’objet _meta, avec des endpoints spécifiques.

… et au niveau application

Le passage au stateless et au sessionless a exigé des travaux sur de nombreux composants annexes de MCP. Par exemple les tâches. Ce mode d’exécution alternatif, utile pour représenter notamment, les opérations de batch, avait été intégré dans la spec 2025-11-25. Avec la nouvelle version, il sort du cœur du protocole et devient une extension officielle.

Il a aussi fallu instaurer une alternative aux sessions pour la gestion d’état au niveau des applications. La solution retenue se fonde sur des identifiants explicites générés côté serveur et transmis en tant qu’arguments. Plusieurs éléments ont dû être clarifiés dans ce cadre, comme l’absence de mécanisme natif pour communiquer le TTL de ces identifiants ou le risque de production d’états orphelins en cas de compression du contexte.

Du stateless également pour les demandes d’informations supplémentaires par les serveurs

Entre autres changements majeurs, la spec 2026-07-28 introduit aussi le pattern MRTR (Multi Round-Trip Requests) comme moyen, pour les serveurs, de signaler qu’il leur faut des informations supplémentaires pour traiter une requête. Son principale avantage : pas besoin de couche de stockage partagée entre instances de serveurs, ni de load balancer stateful.

Il y a également des avancées sur la partie autorisation (la plus coûteuse en effort d’intégration). En particulier, l’adoption de CIMD (Client ID Metadata Documents) à la place de DCR (Dynamic Client Registration), qui reste pour le moment pris en charge pour la rétrocompatibilité. Les authentifiants clients sont en outre désormais liés à leur émetteur : on ne peut plus les réutiliser entre serveurs d’autorisation.

Tous les SDK de premier niveau (TypeScript, Python, Go, C#) gèrent la nouvelle spec. Le SDK Rust aussi, mais en bêta.

Illustration principale générée par IA

The post MCP devient un protocole sans état… et sans session appeared first on Silicon.fr.