Le Model Context Protocol a franchi une étape majeure en matière d'infrastructure : sa révision du 28/07/2026 fait évoluer le protocole vers un noyau sans état. Pour les équipes créant des systèmes d’agents, des serveurs d’outils, des intégrations IDE ou des couches d’orchestration multimodèles, il ne s’agit pas d’une mise à jour de spécifications cosmétiques. Cela modifie les hypothèses concernant les sessions, l'initialisation, la mise à l'échelle, la compatibilité et la gouvernance.

La version candidate MCP a décrit la spécification du 28 juillet comme l'ajout d'un noyau de protocole sans état, d'un cadre d'extensions, de tâches, de MCP applications, d'un renforcement des autorisations et d'une politique de dépréciation formelle. Le blog officiel MCP a également averti que la version contenait des modifications importantes. GitHub, qui exploite l'une des implémentations de serveur MCP les plus visibles, a déclaré avant la version finale que son serveur MCP prenait déjà en charge la nouvelle spécification et a décrit le protocole comme « devenant sans état » le 28 juillet.

La signification pratique est simple : MCP se présente moins comme une couche d'intégration locale gourmande en sessions que comme un protocole à l'échelle Internet pour l'accès aux outils à distance. C’est important car les systèmes d’agents ne se limitent plus aux outils de développement de bureau. Ils s'exécutent de plus en plus au sein de services cloud, de systèmes CI, de workflows de support client, de suivi des problèmes et de plates-formes d'automatisation d'entreprise.

Ce qui a changé en MCP

Le changement majeur est le passage à un cœur de protocole sans état. Le journal des modifications de GitHub indique que le nouveau noyau supprime les sessions et s'initialise, dans le but de faciliter la mise à l'échelle des déploiements à distance MCP. Il s’agit d’un changement architectural important. Les protocoles avec état peuvent bien fonctionner pour les outils locaux et les environnements contrôlés, mais ils compliquent la mise à l'échelle horizontale, l'exécution sans serveur, le basculement, le déploiement en périphérie et l'équilibrage de charge.

Un noyau sans état donne aux développeurs plus de liberté pour exécuter MCP des serveurs derrière une infrastructure Web ordinaire. Les requêtes peuvent être distribuées entre les instances sans conserver une session de longue durée sur un backend spécifique. Pour les grandes organisations, cela peut réduire la complexité opérationnelle. Pour les petites équipes, cela peut faciliter le déploiement des MCP serveurs hébergés à l'aide d'un calcul géré plutôt que d'une infrastructure personnalisée à long terme.

La version plus large du 28/07/2026 introduit également un cadre d'extensions et des tâches, selon les documents de la version candidate. Ces ajouts suggèrent que MCP devient plus modulaire et plus explicite sur les travaux à plus long terme. MCP Le renforcement des applications et des autorisations va dans la même direction : le protocole évolue depuis les débuts de l'écosystème vers une couche plus formelle pour l'interaction agent-outil.

Le coût de cette maturation est le travail de compatibilité. Le blog MCP a caractérisé la version comme une version comportant des modifications importantes, et les documents TypeScript et C# SDK publiés autour de la révision se concentrent sur la prise en charge de la migration et les concepts sans état. Toute équipe exploitant un MCP serveur, intégrant MCP dans une extension IDE ou acheminant les appels d'agent via l'infrastructure interne doit traiter la révision comme un événement d'ingénierie plutôt que comme une mise à jour des normes en arrière-plan.

Pourquoi l'absence d'état MCP est importante pour les développeurs et les opérateurs

Les outils d'agent ont un problème de mise à l'échelle qui semble différent de la mise à l'échelle API ordinaire. Une seule demande d'utilisateur peut déclencher de nombreux appels d'outils, changements de modèle, tentatives, lectures de fichiers, requêtes de recherche et étapes d'approbation. Lorsque le protocole de l'outil suppose des sessions durables, les opérateurs de production doivent préserver l'état dans ces interactions ou créer des solutions de contournement autour du protocole.

En supprimant les sessions du noyau, MCP s'adapte mieux aux environnements dans lesquels les charges de travail des agents sont en rafale, distribuées et asynchrones. Les fonctions sans serveur, les travailleurs de périphérie, les déploiements Kubernetes et les systèmes multirégionaux bénéficient tous du fait que les demandes peuvent être traitées de manière indépendante.Cela n’élimine pas l’état des applications d’agent ; il déplace l'état dans les bases de données d'application, les files d'attente de tâches, les systèmes d'identité ou les couches de flux de travail explicites plutôt que de l'intégrer dans le cœur du protocole.

Pour les développeurs, ce changement devrait à terme rendre les serveurs d'outils distants plus faciles à utiliser. Pour les équipes de plateforme, cela peut simplifier l’observabilité et la planification des capacités. Au lieu de déboguer un comportement d'affinité de session opaque, les opérateurs peuvent se concentrer sur les traces au niveau des requêtes, la latence des appels d'outils, les décisions d'autorisation et les modèles d'erreurs.

Il existe également un angle de gouvernance. À mesure que MCP devient plus courant dans les assistants de codage et les agents d'entreprise, les entreprises auront besoin de politiques concernant les outils que les agents peuvent appeler, les données auxquelles ils peuvent accéder et les utilisateurs ou services autorisés à les invoquer. Le durcissement Authorization dans la nouvelle révision n'est donc pas fortuit. Cela reflète la réalité selon laquelle l'accès aux outils est désormais une limite de sécurité, et non seulement une commodité pour les développeurs.

Qui est concerné

Les groupes les plus directement concernés sont MCP responsables de la maintenance du serveur, SDK utilisateurs, équipes de plate-forme d'agents et organisations exposant des outils internes aux agents IA. Si un serveur dépend du comportement de la session ou d'anciens flux d'initialisation, il devra être testé par rapport à la nouvelle spécification. Si une application prend en charge plusieurs MCP versions, elle peut nécessiter une négociation de version, des couches de compatibilité ou un plan de migration par étapes.

Les fournisseurs d'IDE et d'outils de développement sont également concernés. MCP apparaît de plus en plus aux côtés des agents de codage, des agents personnalisés et des fonctionnalités de gestion de modèles. Un noyau de protocole sans état permet à ces produits d'appeler plus facilement des outils distants de manière fiable, mais uniquement si leurs intégrations suivent le rythme des spécifications.

Les entreprises utilisant l'automatisation des agents doivent y prêter attention même si elles ne lisent jamais la spécification MCP. Ce changement peut affecter la fiabilité des agents qui se connectent aux référentiels, aux systèmes de tickets, aux bases de données, aux bases de connaissances internes ou aux outils de déploiement. Pendant les fenêtres de migration, les modes de défaillance probables ne sont pas seulement des pannes évidentes. Ils peuvent inclure des fonctionnalités d'outil manquantes, un comportement d'authentification modifié ou des agents empruntant des chemins différents parce qu'un serveur d'outils ne se comporte plus comme prévu.

Pour une passerelle IA API telle que Model Gate, la connexion est pratique. Une IA unifiée API se situe de plus en plus à proximité du routage des modèles, de la API gestion des clés, de l'analyse de l'utilisation et de la gouvernance de l'équipe API. À mesure que les systèmes d'agents ajoutent MCP appels d'outils en plus des appels de modèle ordinaires, les couches de passerelle et d'observabilité devront tenir compte des deux côtés du flux de travail : quel modèle a été utilisé, quels outils ont été invoqués, combien ils coûtent, qui les a autorisés et où les échecs se sont produits.

Priorités de migration et questions ouvertes

La première priorité de migration est les tests de compatibilité. Les équipes doivent inventorier MCP clients et serveurs, identifier les dépendances sur les sessions ou initialiser le comportement, et tester par rapport aux SDK 2026-07-28 ou aux documents de conformité, le cas échéant. Les systèmes de production doivent organiser la mise à niveau, en particulier si les agents effectuent des actions ayant des effets secondaires, telles que la création de demandes d'extraction, la modification de problèmes, l'interrogation de données client ou l'exécution de workflows de déploiement.

La deuxième priorité est l'observabilité. L'infrastructure sans état peut être plus facile à faire évoluer, mais les systèmes d'agents distribués ont toujours besoin d'ID de corrélation, de capture de trace, de journaux de requêtes et d'événements de stratégie. Sans cela, les équipes peuvent troquer la complexité des sessions contre la complexité du débogage. Les analyses d'utilisation doivent faire la distinction entre les appels de modèle et les appels d'outils, en particulier lorsque les flux de travail des agents sont facturés, limités en débit ou audités par l'équipe.

La troisième priorité est l'examen des autorisations. Si la nouvelle spécification renforce la sémantique d'autorisation, les implémenteurs ne doivent pas simplement porter les anciennes hypothèses d'accès dans la nouvelle version. Ils doivent revérifier la portée des jetons, la délégation des utilisateurs, les comptes de service, les journaux d'audit et le comportement de refus.L'accès aux outils doit être limité par défaut au niveau de moindre privilège, en particulier pour les MCP déploiements à distance.

Certains détails méritent d'être vérifiés avant que les organisations ne prennent des décisions de conception irréversibles. Les recherches disponibles pour cet article comprenaient la version candidate, la page de spécifications, les documents de migration SDK et la note d'implémentation de GitHub. Le libellé normatif final de la spécification du 28/07/2026 doit être révisé directement avant de citer les exigences exactes du protocole dans les normes internes ou la documentation client.

Même avec cette mise en garde, la direction est claire. MCP devient un protocole davantage orienté production pour l'infrastructure d'agent. Le noyau sans état devrait faciliter la mise à l'échelle des déploiements à distance, mais il oblige également l'écosystème à nettoyer les hypothèses des implémentations antérieures. Pour les équipes constituées d'agents, c'est le genre de changement de protocole qui mérite un ticket de sprint, pas seulement un signet.