Le piège de l'état qui entravait MCP
Le protocole initial de MCP imposait une contrainte architecturale significative : une gestion d'état inhérente. Auparavant, un client initiait l'interaction avec une requête initialize vers un point de terminaison MCP. Le serveur créait et renvoyait alors un session ID unique, un jeton essentiel pour toute communication ultérieure entre le client et le serveur. Chaque requête de suivi devait porter cet identifiant.
Cette conception a créé une faille fondamentale pour les déploiements évolutifs. Le session ID obligatoire liait le client à l'instance de serveur spécifique qui avait initialement traité l'appel initialize. Cela brisait les paradigmes standards d'équilibrage de charge. Si un équilibreur de charge, par exemple un routeur round-robin, dirigeait une requête ultérieure vers une instance différente, ce serveur n'aurait aucune trace de la session. Le résultat était une erreur 400 "session not found" invalidante, interrompant les opérations du client. De même, si une instance tombait en panne, tous ses états de session actifs étaient instantanément perdus, provoquant des échecs immédiats des requêtes client.
Les développeurs étaient contraints d'utiliser des solutions de contournement complexes et inefficaces pour atténuer ces problèmes. Les solutions courantes incluaient la mise en œuvre de sticky sessions, qui garantissaient qu'un client atteignait systématiquement la même instance de serveur. Une autre approche impliquait le déploiement de magasins d'état partagés, tels qu'une instance Redis, pour centraliser et synchroniser les données de session sur tous les serveurs. Les deux méthodes introduisaient une surcharge opérationnelle inutile, augmentaient la latence réseau et accroissaient considérablement les coûts d'infrastructure. Il s'agissait de fardeaux induits par le protocole, et non de choix.
Sans état par défaut : un protocole renaît
La nouvelle spécification de MCP, '2026-07-28', introduit un changement radical. Deux propositions clés, SEP-2575 et SEP-2567, redéfinissent le cœur du protocole. SEP-2575 élimine la poignée de main initialize et initialized, tandis que SEP-2567 supprime l'en-tête MCP-Session-Id et sa session associée au niveau du protocole.
Ces changements transforment un appel d'outil en plusieurs étapes en une requête HTTP unique et autonome. Auparavant, le contexte était fragmenté ; désormais, toutes les informations nécessaires sont transmises dans un champ meta au sein du corps JSON. Cette conception rend chaque requête indépendante, reflétant les principes HTTP sans état.
L'alignement avec l'infrastructure HTTP standard est complet. Les nouveaux en-têtes, MCP-Method et MCP-Name, transportent désormais des informations de routage critiques. Cela permet aux composants réseau tels que les passerelles, les pare-feu et les limiteurs de débit de prendre des décisions sans analyser la charge utile JSON. Une telle efficacité est cruciale pour les performances, en particulier sur Cloudflare.
Le protocole ne nécessite plus de Durable Objects pour parler MCP, ce qui simplifie le déploiement. Les services peuvent passer à zéro lorsqu'ils sont inactifs, réduisant considérablement les coûts opérationnels et élargissant les options de déploiement. Ce changement élimine les points de friction des sticky sessions ou des instances Redis partagées, rendant MCP véritablement sans état par défaut.
Infrastructure plus intelligente et état de l'application
L'absence d'état débloque des avantages de déploiement massifs. Les plateformes serverless comme Cloudflare Workers et Google Cloud Run passent désormais à zéro lorsqu'elles sont inactives, réduisant radicalement les coûts opérationnels. Les serveurs ne maintiennent plus de connexions persistantes, éliminant le besoin d'instances toujours actives pour conserver l'état de la session. Cela modifie fondamentalement le provisionnement de l'infrastructure.
Le protocole n'alourdit plus la gestion d'état. Au lieu de cela, l'état devient une préoccupation au niveau de l'application. Les outils peuvent créer des identifiants explicites, comme un basket_id ou un browser_id. Le modèle renvoie ensuite cet identifiant comme un argument ordinaire lors des appels d'outils ultérieurs. Cela offre aux développeurs une plus grande flexibilité, leur permettant de gérer l'état précisément selon leurs besoins, plutôt que de se conformer à des modèles imposés par le protocole.
MCP adopte une mise en cache inspirée de HTTP pour une efficacité accrue côté client. De nouvelles indications de time to live et de cache scope informent les clients sur la fraîcheur des listes d'outils, de prompts et de ressources. Cela permet aux clients de mettre en cache les réponses en toute confiance, évitant ainsi des connexions persistantes pour les mises à jour. Pour en savoir plus sur la conception robuste d'API sans état, explorez Statelessness in API Design: Understanding & Examples - Unkey. Ces indications garantissent que les clients savent précisément combien de temps les données restent valides pour les utilisateurs.
Cet article vous plaît ? Recevez-en un comme celui-ci chaque matin.
un e-mail par jour · désinscription en deux clics · aucun traqueur tiers
Nouveaux modèles pour des interactions complexes
Les interactions complexes suivent désormais un modèle clair, piloté par le client. Auparavant, le serveur envoyait des questions de suivi non sollicitées, ce qui représentait un risque de sécurité. La nouvelle spécification empêche cela. Pour les interactions en plusieurs étapes, le serveur renvoie un résultat input_required.
Ce résultat inclut une charge utile request_state sérialisée, encapsulant tout le contexte de l'action en attente. Un client reçoit input_required, sollicite l'utilisateur (par exemple, « Êtes-vous sûr ? »), puis relance la requête initiale. Le client joint la réponse de l'utilisateur et renvoie le request_state. Cela garantit que le client pilote toujours l'interaction. N'importe quelle instance de serveur peut reprendre la requête, renforçant ainsi l'absence d'état (statelessness).
Les opérations de longue durée tirent parti de l'extension 'tasks' désormais officielle. Cette fonctionnalité est passée du statut expérimental à celui de fonctionnalité officielle. Pour une tâche comme le traitement d'un remboursement, le serveur accuse réception de la demande immédiatement. Il renvoie une réponse indiquant que la tâche est en cours, évitant ainsi le blocage de la connexion.
Les clients suivent ensuite la progression de manière asynchrone. Ils peuvent interroger via tasks/get ou s'abonner via subscriptions/listen. Cela permet de récupérer le résultat final une fois la tâche de longue durée terminée. Cette conception élimine le besoin de connexions persistantes lors de calculs longs, améliorant ainsi l'efficacité et la résilience du protocole.
Foire aux questions
Quel était le problème principal avec l'ancien MCP avec état ?
L'ancien protocole nécessitait des ID de session qui liaient les clients à des instances de serveur spécifiques. Cela rendait l'équilibrage de charge difficile, nécessitait des solutions complexes comme les sessions persistantes (sticky sessions) ou Redis, et rendait le système fragile, car un redémarrage du serveur pouvait entraîner la perte de l'état de la session.
Comment le nouveau MCP sans état résout-il ces problèmes ?
Il supprime entièrement les poignées de main et les ID de session (spécification 2026-07-28). Chaque requête est autonome, permettant un équilibrage de charge standard (round-robin), une résilience améliorée et la capacité pour les serveurs de réduire leur activité jusqu'à zéro, réduisant ainsi les coûts.
Comment l'état est-il géré dans le nouveau MCP si le protocole est sans état ?
L'état est désormais géré au niveau de l'application, et non au niveau du protocole. Les développeurs peuvent faire en sorte qu'un outil crée un identifiant explicite (par exemple, 'browser_id') que le modèle renvoie lors des appels ultérieurs, un modèle flexible courant dans les API HTTP standard.
Que se passe-t-il pour les appels d'outils de longue durée sans connexion persistante ?
La nouvelle spécification fait passer l'extension 'tasks' au rang de fonctionnalité officielle. Pour une tâche longue, le serveur peut immédiatement renvoyer un ID de tâche, et le client peut ensuite interroger ou s'abonner à cette tâche pour obtenir des mises à jour de progression et le résultat final de manière asynchrone.