Le 28 juillet 2026, une nouvelle révision de la spécification du Model Context Protocol a été publiée. Elle porte l'identifiant 2026-07-28 et succède à 2025-11-25. Si tu maintiens un serveur MCP, que tu l'exposes via l'API Anthropic ou en local via stdio, cette version introduit un changement d'architecture assez radical : le cœur du protocole devient stateless. La poignée de main initialize, les notifications initialized et l'en-tête Mcp-Session-Id disparaissent. Chaque requête porte sa propre version de protocole et ses capacités dans un champ _meta.
Cet article détaille ce qui casse, ce qui devient obligatoire, et surtout ce qu'il faut migrer en priorité. Si tu débutes sur MCP et que le vocabulaire (transport, SSE, tools, resources) ne te dit rien encore, commence plutôt par le guide pour apprendre Claude et reviens ensuite. Ici, on suppose que tu as déjà écrit ou modifié un serveur MCP.
Ce qui a changé entre la spec 2025 et la spec 2026-07-28
La spec MCP a suivi une trajectoire assez claire depuis sa publication initiale fin 2024. Chaque révision a ajouté des capacités, mais celle du 28 juillet 2026 est la première à casser le contrat de session au niveau protocole.
| Révision | Nature | Point clé |
|---|---|---|
| 2024-11-05 | Initial | stdio, HTTP+SSE, session au niveau protocole |
| 2025-03-26 | Additif | Introduction du transport Streamable HTTP |
| 2025-06-18 | Additif | Elicitation, améliorations des content types |
| 2026-07-28 | Breaking | Cœur stateless, OAuth 2.1 formalisé, extensions versionnées |
Le tableau ne dit pas tout. Trois choses sortent formellement du cœur du protocole avec la révision 2026-07-28 : MCP Apps (interfaces interactives dans la conversation) et Tasks (tâches longues suivies via un identifiant) passent sous un format versionné distinct. Le transport historique HTTP+SSE, déjà déprécié, garde une fenêtre annoncée d'au moins 12 mois avant retrait. Roots, Sampling et Logging au niveau protocole entrent en dépréciation à leur tour.
Le mode stateless : pourquoi Anthropic pousse cette architecture
La logique est simple. Un serveur MCP qui n'a pas besoin de tenir une session au niveau protocole peut tourner derrière un load balancer, se réveiller à la demande, mourir après 100 ms, sans qu'on ait à propager un Mcp-Session-Id entre instances. Concrètement, ça débloque le déploiement serverless : Cloudflare Workers, Vercel Functions, AWS Lambda.
Ce que ça change dans un serveur TypeScript minimal :
// Avant (spec 2025-11-25)
// Le serveur maintenait une session côté transport,
// initialize() était un handshake obligatoire.
server.initialize({ capabilities: {...} });
// Après (spec 2026-07-28)
// Chaque requête porte sa version et ses capacités.
// Pas de handshake. Pas de session côté protocole.
app.post('/mcp', async (req, res) => {
const { _meta, method, params } = req.body;
// _meta contient protocolVersion et clientCapabilities
const result = await handleTool(method, params, _meta);
res.json(result);
});Le piège : si ton serveur a besoin d'état entre appels (curseur de pagination, résultat intermédiaire d'un calcul long), tu dois désormais le matérialiser toi-même. La spec recommande des handles, des identifiants opaques que ton serveur émet et que le client repasse comme arguments d'outil ordinaires. Ça ressemble à un token de continuation. Ce n'est pas plus complexe, mais ça déplace la responsabilité : à toi de gérer TTL, éviction, sécurisation de ces handles.
Le mode stateful reste possible, la spec ne l'interdit pas. Elle le sort simplement du cœur du protocole. Pour un serveur MCP qui pilote un long processus (par exemple un agent qui explore un dépôt, à rapprocher de ce que fait le runner self-hosted de Claude Code), tu construis ton propre mécanisme de session par-dessus.
OAuth 2.1 obligatoire pour les serveurs distants
C'est le point qui va faire mal aux serveurs déjà en production. La révision 2026-07-28 formalise les serveurs MCP comme des resource servers au sens OAuth 2.1, avec alignement sur OpenID Connect, dont la validation du paramètre iss selon la RFC 9207.
Traduction : le bearer token statique dans un header Authorization, valable trois ans, généré à la main dans une variable d'environnement, c'est fini pour tout serveur exposé en HTTP distant. Il faut un flux d'autorisation en bonne et due forme, avec metadata endpoint, discovery, et validation d'issuer.
Un endpoint minimal conforme ressemble à ça :
GET /.well-known/oauth-protected-resource
{
"resource": "https://mcp.monserveur.com",
"authorization_servers": ["https://auth.monserveur.com"],
"bearer_methods_supported": ["header"],
"resource_documentation": "https://docs.monserveur.com/mcp"
}Le serveur d'autorisation lui-même (/authorize, /token) peut être hébergé par un fournisseur d'identité externe compatible OAuth 2.1 plutôt que développé maison. Pour un dev solo, la question devient : monter sa propre stack OIDC, ou déléguer cette brique à un service tiers spécialisé dans l'authentification. Le choix dépend surtout du temps que tu es prêt à investir dans une brique qui n'est pas ton produit.
Pour un serveur stdio local (celui que tu lances via claude mcp add et qui tourne en sous-processus), rien de tout ça ne s'applique. Le transport stdio n'a pas d'autorisation formelle, la confiance vient du fait que le processus tourne sur ta machine. Si ton usage MCP se limite à un serveur qui lit tes fichiers locaux ou appelle une CLI, tu peux ignorer cette section entière.
Les nouveaux types de contenu : ressources structurées et elicitation
L'elicitation existait déjà en 2025-06-18, elle est stabilisée dans la révision de juillet 2026. L'idée : pendant l'exécution d'un tool, le serveur peut demander une information supplémentaire à l'utilisateur (via le client) avant de continuer. Utile pour confirmer une action destructive, demander un choix parmi plusieurs, ou récupérer un paramètre qu'on ne voulait pas passer au premier appel.
// Tool avec elicitation avant action destructive
async function deleteRepository({ repo }, ctx) {
const confirmation = await ctx.elicit({
message: `Supprimer ${repo} ? Cette action est irréversible.`,
schema: {
type: 'object',
properties: {
confirm: { type: 'boolean' },
typedName: { type: 'string' }
},
required: ['confirm', 'typedName']
}
});
if (!confirmation.confirm || confirmation.typedName !== repo) {
return { content: [{ type: 'text', text: 'Annulé.' }] };
}
await github.deleteRepo(repo);
return { content: [{ type: 'text', text: 'Supprimé.' }] };
}C'est particulièrement pertinent quand tu regardes la direction que prend Claude Code avec son mode auto par défaut : le classifieur bloque déjà les actions jugées irréversibles, mais un tool bien conçu peut aussi porter sa propre couche de confirmation via elicitation. Les deux mécanismes ne s'excluent pas.
Les ressources structurées, elles, permettent de renvoyer du JSON typé plutôt que du texte que le client doit reparser. Un tool qui liste des tickets peut désormais renvoyer directement un tableau d'objets typés, le client (Claude Desktop, Claude Code, ou un autre) sait quoi en faire.
Migrer un serveur MCP existant : la checklist
L'ordre compte. Voici la séquence qui minimise les régressions :
- Bump le SDK officiel (
@modelcontextprotocol/sdken TypeScript,mcpen Python) vers la version qui déclare le support de2026-07-28. Vérifie le changelog pour les breaking changes internes au SDK, qui vont au-delà de la spec elle-même. - Remplace tout usage restant du transport HTTP+SSE historique par Streamable HTTP. Le SSE reste supporté pendant la fenêtre de dépréciation, mais tout nouveau déploiement doit passer sur Streamable.
- Si ton serveur est distant, ajoute la couche OAuth 2.1. Publie ton
/.well-known/oauth-protected-resource. Teste le flux end-to-end avec un client de référence. - Retire toute logique qui dépend de la session au niveau protocole. Cherche les usages de
Mcp-Session-Id,initialize,initialized. Remplace par des handles applicatifs si tu as besoin d'état. - Vérifie que tes tools qui utilisent
Roots,SamplingouLoggingau niveau protocole ont un plan de migration. Ces primitives passent en dépréciation, elles fonctionnent encore, mais tout nouveau code doit les éviter. - Passe le serveur à l'Inspector MCP officiel. Puis teste avec Claude Desktop en local, puis avec Claude Code, puis avec l'API Anthropic si ton serveur y est déclaré comme connecteur. Les trois clients ne se comportent pas exactement pareil sur les cas limites.
Le breaking change le plus vicieux, c'est la négociation de version. En 2025, elle passait par initialize. En 2026-07-28, elle passe par _meta.protocolVersion dans chaque requête. Un client à jour qui parle à un serveur non migré va se retrouver à envoyer une version que le serveur ne comprend pas, et vice versa. Prévois une bascule courte, pas un doublon long.
Ce que ça change pour un entrepreneur qui construit sur Claude
Il faut séparer deux mondes.
Si ton usage MCP se résume à un serveur stdio local, lancé par Claude Desktop ou Claude Code sur ta machine, qui lit tes fichiers, appelle une CLI, ou parle à une API interne : l'impact est marginal. Bump ton SDK quand une release stable sort, et tu es tranquille. Le stateless, l'OAuth, la dépréciation du SSE, tout ça ne te concerne pas directement. Tu peux continuer à construire des serveurs MCP comme avant et te concentrer sur la partie qui apporte de la valeur.
Si tu exposes un serveur MCP en SaaS, que plusieurs clients (humains ou agents) s'y connectent via HTTP, alors la migration OAuth n'est pas optionnelle. C'est la partie qui va te coûter le plus de temps, et c'est celle qu'il faut planifier en premier. Regarde aussi la direction des connecteurs officiels : quand un acteur comme HubSpot met à jour son serveur MCP (comme dans l'extension de juillet 2026), il porte déjà la charge OAuth pour toi. Ça peut valoir le coup de s'aligner sur les mêmes patterns.
Quand migrer ? La spec précédente reste fonctionnelle pendant la fenêtre de dépréciation d'au moins 12 mois. Rien ne casse du jour au lendemain. Mais tout nouveau serveur, tout code écrit à partir de maintenant, doit cibler 2026-07-28. Pour un serveur en production sans dépendance forte au stateful, la migration prend quelques jours. Avec OAuth à greffer, compte plutôt deux à trois semaines pour un dev qui n'a jamais implémenté OAuth 2.1 from scratch, moins avec un provider managé.
Le vrai levier reste ailleurs. Une spec propre ne fait pas un produit. Ce qui compte, c'est ce que ton serveur MCP permet à un agent Claude de faire dans le workflow d'un utilisateur payant. Si tu veux monter en compétence sur la partie construction produit autour de Claude et MCP, la formation Construire votre produit IA en 5 semaines couvre exactement ce chemin : de la spec technique à l'application déployée sur Vercel, avec un backend Supabase et des connecteurs MCP en production. Deux sessions live par semaine pendant cinq semaines, et une app en ligne à la fin.