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.
