MCP devient « sans état » : ce que change la spécification 2026-07-28

Le Model Context Protocol (MCP) est le standard qui permet à un assistant IA de se brancher sur des outils et des données : un agenda, une base de données, un CRM. Sa version du 28 juillet 2026 est la plus grosse refonte depuis son lancement. Si vous maintenez un serveur MCP, ou si vous comptez en faire développer un, voici l'essentiel.

L'idée centrale : chaque requête se suffit à elle-même

Jusqu'ici, un client et un serveur MCP ouvraient une session : une poignée de main au départ, puis un identifiant de session à conserver des deux côtés. C'est terminé. Désormais, chaque requête transporte tout ce qu'il faut : version du protocole, identité du client, capacités.

La conséquence est très concrète pour l'hébergement. N'importe quelle requête peut arriver sur n'importe quelle instance du serveur, derrière un répartiteur de charge ordinaire, sans stockage partagé. Un serveur MCP distant se déploie comme une API web classique, y compris sur des plateformes « serverless ».

Si votre application a vraiment besoin de mémoire entre deux appels, la consigne est de créer un identifiant explicite avec un outil, que le modèle renvoie ensuite en argument.

Les autres changements

• Demander une précision en cours d'appel. Quand un outil a besoin d'une confirmation ou d'un paramètre manquant, le serveur répond « il me faut ceci », et le client relance l'appel avec la réponse. Plus besoin de garder une connexion ouverte.
• Des en-têtes HTTP lisibles. Le nom de la méthode et de l'outil figurent dans les en-têtes. Pare-feu applicatifs et limiteurs de débit peuvent filtrer sans décoder le contenu.
• Des listes d'outils mises en cache. Les réponses indiquent leur durée de validité et arrivent dans un ordre stable.
• Une autorisation durcie. Plusieurs failles possibles du parcours OAuth sont fermées, et les applications de bureau ne se font plus refuser leurs redirections locales.
• Un cadre officiel pour les extensions. Les tâches longues, les MCP Apps et l'autorisation gérée par l'entreprise deviennent des extensions nommées, hors du cœur du protocole.

Ce qui est déprécié

• Les fonctions Roots, Sampling et Logging : elles fonctionnent encore, pour au moins douze mois, mais ne doivent plus être adoptées.
• L'ancien transport HTTP+SSE : un an de sursis.
• L'enregistrement dynamique des clients (DCR), remplacé par des documents de métadonnées d'identité client (CIMD).

Le protocole se dote au passage d'une règle : toute fonction dépréciée reste disponible douze mois au minimum avant son retrait.

Faut-il migrer tout de suite ?

Les kits de développement officiels TypeScript, Python, Go et C# gèrent déjà cette version, et Rust est en bêta. Les mainteneurs reconnaissent que la migration a un coût, surtout pour les serveurs qui s'appuyaient sur l'identifiant de session.

Notre conseil pour une petite équipe : mettez à jour le kit de développement, lisez ses notes de migration, et repérez d'abord tout ce qui dépend d'une session. C'est là que se trouve l'essentiel du travail. Pour un nouveau serveur, partez directement sur le modèle sans état.

Pourquoi c'est important

D'après les mainteneurs, les kits officiels approchent le demi-milliard de téléchargements par mois. À cette échelle, un protocole qui impose des connexions longues et des sessions devenait un frein. Cette version aligne MCP sur les pratiques habituelles du web, ce qui le rend plus simple à héberger, à surveiller et à sécuriser.