Quand la spécification MCP sans état entre-t-elle en vigueur ?

La version candidate a été verrouillée le 21 mai 2026 et la spécification finale est publiée le 28 juillet 2026, portant la chaîne de version 2026-07-28. Le RC est figé en fonctionnalités, donc tout ce que vous construisez maintenant correspondra aux spécifications finales. Les serveurs des anciennes révisions 2025 continuent de fonctionner dans le cadre de la nouvelle politique de dépréciation de 12 mois, mais le transport sans état est l'endroit où chaque nouveau client atterrira.

Qu'est-ce qui est exactement supprimé dans le noyau apatride ?

The initialize/initialized handshake and the Mcp-Session-Id header are gone. Un serveur ne conserve plus d'objet de session entre les requêtes. Les métadonnées du protocole qui vivaient auparavant dans la session se déplacent désormais dans le champ _meta à chaque requête, et les clients récupèrent les fonctionnalités avec une nouvelle méthode serveur/découverte au lieu de les lire une seule fois au moment de la connexion.

Dois-je réécrire mon serveur MCP ?

Seule la couche de transport. Les gestionnaires d’outils, les schémas et les descriptions restent intacts. Vous supprimez le magasin de session, arrêtez de lire Mcp-Session-Id, lisez les métadonnées du protocole à partir de _meta par requête et ajoutez les en-têtes de requête Mcp-Method et Mcp-Name afin qu'un équilibreur de charge puisse acheminer sans inspecter le corps. Un serveur qui était déjà apatride en coulisses ne nécessite pratiquement aucun travail.

Comment l’État survit-il si le protocole est apatride ?

Grâce à des modèles de poignées explicites. Un appel d’outil renvoie un identifiant et le modèle renvoie cet identifiant lors de l’appel suivant. L'état réside dans votre magasin de données saisi par le handle, et non dans une session de protocole. Il s'agit du même modèle que les API REST utilisent depuis des années : la requête contient tout ce dont le serveur a besoin pour agir, donc n'importe quelle instance peut la servir.

Qu'est-ce qui a changé dans l'autorisation ?

Six propositions d'amélioration des spécifications ont renforcé l'alignement d'OAuth 2.0 et d'OpenID Connect. L'exigence principale consiste à valider le paramètre iss selon la RFC 9207 pour arrêter l'injection de code d'autorisation entre les serveurs, ainsi que des règles plus claires sur la rotation des jetons d'actualisation et l'accumulation de portée. Si vous expédiez un serveur MCP authentifié, la vérification iss est la seule modification que vous ne pouvez pas ignorer.

Guide

MCP est devenu apatride : 5 modifications apportées par la spécification 2026 à votre serveur

3 juin 2026 | 8 min read

La version candidate de la spécification MCP a été verrouillée le 21 mai 2026 et expédiée le 28 juillet en tant que version 2026-07-28. Noyau sans état, tâches, extensions, applications MCP et renforcement OAuth, avec les modifications de transport exactes dont les auteurs de serveurs ont besoin.

Data center network switches representing stateless MCP transport — Photo by Taylor Vick on Unsplash

La version candidate du Model Context Protocol a été verrouillée le 21 mai 2026. Elle est livrée en version 2026-07-28 le 28 juillet, et le changement de titre réécrit la façon dont chaque serveur gère un requête : MCP est sans état au niveau de la couche de protocole. Non initialize poignée de main, non Mcp-Session-Id, pas de routage collant. Toute demande peut atterrir sur n’importe quelle instance.

Si vous exécutez un serveur MCP derrière un équilibreur de charge, cela supprime l'unique élément d'infrastructure qui rendait la mise à l'échelle horizontale ennuyeuse : le magasin de sessions partagées. Voici les cinq changements qui important et les modifications de transport exactes dont vous avez besoin avant que les clients ne commencent à envoyer la nouvelle version.

1. Le noyau sans état supprime la poignée de main

Le transport 2025 s'est ouvert avec un initialize/initialized échange. Le le serveur a créé une session, a rendu un Mcp-Session-Id, et le client l'a répété sur chaque demande ultérieure. Cette session devait vivre quelque part à la fois sur l'équilibreur de charge et sur le serveur pouvait atteindre, vous avez donc exécuté des sessions persistantes ou un magasin partagé.

Les transports de 2026 suppriment tout cela. Métadonnées de protocole qui vivaient désormais dans la session roule dans un _meta champ à chaque demande. Les clients lisent les capacités grâce à un nouveau server/discover méthode au lieu de les lire une fois au moment de la connexion. Le résultat : aucun objet de session à perdre, aucune instance à laquelle épingler.

2. Le routage se déplace dans les en-têtes de requête

Puisqu'il n'y a pas de session à inspecter, la spécification ajoute Mcp-Method et Mcp-Name en-têtes de requête afin qu'un proxy puisse acheminer sans analyser le corps JSON-RPC. UN tools/call pour dns_lookup porte les deux dans l'en-tête, et votre avantage peut envoyez des outils lourds vers un pool plus grand sans rien désérialiser.

Vous pouvez confirmer qu'un serveur déployé parle le nouveau transport en inspectant ce qu'il renvoie à un simple demande. Le point de terminaison des en-têtes botoi affiche l'état de la réponse et les en-têtes de n'importe quelle URL. vous pouvez vérifier le point de terminaison d'un MCP Allow et les en-têtes CORS sans écrire de client :

3. L’État survit grâce à des identifiants explicites

Transport apatride ne signifie pas outils apatrides. Un travail de longue haleine doit encore être suivi progrès. La réponse de la spécification est le modèle de handle explicite : un appel d'outil renvoie un ID, le modèle transmet cet identifiant lors du prochain appel, et l'état réside dans votre magasin de données saisi par le handle. N'importe quelle instance peut servir de suivi car la requête porte la clé.

Il s'agit de la même forme qu'utilise une API REST. La requête contient tout ce dont le serveur a besoin, vous évoluez en ajoutant des pods, et non en synchronisant les sessions. Le serveur botoi MCP fonctionne déjà de cette façon : apatride, un nouveau gestionnaire par requête, la clé API transmise dans les en-têtes.

4. Diplômé des tâches, des extensions et des applications MCP

Trois fonctionnalités formalisent dans cette révision :

Tâches déplacé d'une fonctionnalité principale expérimentale vers une extension avec un nettoyeur cycle de vie. Les clients stimulent le progrès avec tasks/get, tasks/update, et tasks/cancel plutôt que l’ancienne conception du sondage.
Rallonges portent désormais des identifiants DNS inversés, négocient via la capacité cartes, versions indépendantes et suivent leur propre piste de proposition d'amélioration des spécifications. Vous expédier une fonctionnalité sans attendre une version principale.
Applications MCP laissez un serveur renvoyer du HTML interactif rendu dans une iframe en bac à sable. Chaque action de l'interface utilisateur passe par le même chemin d'audit qu'un appel d'outil, donc un clic sur un bouton est enregistré and permission-checked like any other operation.

5. L'autorisation se durcit autour de la RFC 9207

Six SEP ont renforcé l'alignement d'OAuth 2.0 et d'OpenID Connect. Le changement que vous ne pouvez pas ignorer : valider le iss paramètre selon RFC 9207. Sans cela, un attaquant peut injecter un code d'autorisation créé par un serveur dans un flux pour un autre, une classe d'attaque inter-serveurs cela touche tout déploiement exécutant plusieurs serveurs MCP derrière une authentification partagée. La spécification aussi clarifies refresh-token rotation and warns against silent scope accumulation across consent écrans.

Une politique de dépréciation formelle accompagne la spécification. Les fonctionnalités passent désormais par Active, Étapes obsolètes et supprimées avec une fenêtre minimale de 12 mois entre la dépréciation et la suppression. Votre serveur 2025 ne tombera pas en panne le 28 juillet ; il entre à la place dans l’horloge de dépréciation.

Votre liste de contrôle de migration

Supprimez le magasin de sessions. Arrêtez de frapper et de lire Mcp-Session-Id. Lire les métadonnées du protocole depuis _meta à chaque demande.
Ajoutez des en-têtes de routage. Émettre et accepter Mcp-Method et Mcp-Name donc votre proxy achemine sans analyser le corps.
Convertissez les sessions en handles. Renvoyez un identifiant à partir des outils avec état et saisissez votre stocker dessus. Any instance answers the follow-up.
Ajoutez le chèque iss. Validez l'émetteur du serveur d'autorisation selon la RFC 9207 sur chaque échange de jetons.
Épingler à 2026-07-28. Construisez contre le RC maintenant ; il est figé et correspond à la spécification finale.

Botoi exploite aujourd'hui un serveur MCP sans état avec 49 outils sélectionnés, afin que vous puissiez étudier une production transport apatride au lieu de deviner. Connectez-le à Claude Code, Cursor ou VS Code depuis le Page de configuration MCP, ou inspecter la réponse de n'importe quel point de terminaison avec /v1/headers de la documents interactifs.

FAQ

Quand la spécification MCP sans état entre-t-elle en vigueur ?: La version candidate a été verrouillée le 21 mai 2026 et la spécification finale est publiée le 28 juillet 2026, portant la chaîne de version 2026-07-28. Le RC est figé en fonctionnalités, donc tout ce que vous construisez maintenant correspondra aux spécifications finales. Les serveurs des anciennes révisions 2025 continuent de fonctionner dans le cadre de la nouvelle politique de dépréciation de 12 mois, mais le transport sans état est l'endroit où chaque nouveau client atterrira.
Qu'est-ce qui est exactement supprimé dans le noyau apatride ?: The initialize/initialized handshake and the Mcp-Session-Id header are gone. Un serveur ne conserve plus d'objet de session entre les requêtes. Les métadonnées du protocole qui vivaient auparavant dans la session se déplacent désormais dans le champ _meta à chaque requête, et les clients récupèrent les fonctionnalités avec une nouvelle méthode serveur/découverte au lieu de les lire une seule fois au moment de la connexion.
Dois-je réécrire mon serveur MCP ?: Seule la couche de transport. Les gestionnaires d’outils, les schémas et les descriptions restent intacts. Vous supprimez le magasin de session, arrêtez de lire Mcp-Session-Id, lisez les métadonnées du protocole à partir de _meta par requête et ajoutez les en-têtes de requête Mcp-Method et Mcp-Name afin qu'un équilibreur de charge puisse acheminer sans inspecter le corps. Un serveur qui était déjà apatride en coulisses ne nécessite pratiquement aucun travail.
Comment l’État survit-il si le protocole est apatride ?: Grâce à des modèles de poignées explicites. Un appel d’outil renvoie un identifiant et le modèle renvoie cet identifiant lors de l’appel suivant. L'état réside dans votre magasin de données saisi par le handle, et non dans une session de protocole. Il s'agit du même modèle que les API REST utilisent depuis des années : la requête contient tout ce dont le serveur a besoin pour agir, donc n'importe quelle instance peut la servir.
Qu'est-ce qui a changé dans l'autorisation ?: Six propositions d'amélioration des spécifications ont renforcé l'alignement d'OAuth 2.0 et d'OpenID Connect. L'exigence principale consiste à valider le paramètre iss selon la RFC 9207 pour arrêter l'injection de code d'autorisation entre les serveurs, ainsi que des règles plus claires sur la rotation des jetons d'actualisation et l'accumulation de portée. Si vous expédiez un serveur MCP authentifié, la vérification iss est la seule modification que vous ne pouvez pas ignorer.

Commencez a construire avec botoi

150+ endpoints API pour la recherche, le traitement de texte, la generation d'images et les utilitaires pour developpeurs. Offre gratuite, sans carte bancaire.

Voir la documentation API Voir tous les outils