Guide
MCP 2026-07-28 : ce qui change dans la spécification
Protocole sans état, fin d'initialize, server/discover, requêtes en plusieurs allers-retours, fonctions dépréciées : la révision 2026-07-28.
Mis à jour le
La révision 2026-07-28 de MCP (Model Context Protocol) est, au relevé du 15/11/2026, la version courante de la spécification. Son changement central : le protocole devient sans état. Il n'y a plus de poignée de main initialize ni de session : chaque requête porte elle-même sa version de protocole et les capacités du client. Si vous avez un serveur ou un client écrit pour la révision 2025-11-25, voici ce qui vous concerne.
Rappel : comment se lisent les versions
Les versions de MCP sont des dates au format AAAA-MM-JJ : elles indiquent la dernière date à laquelle des changements incompatibles ont été introduits. Une révision « courante » peut encore recevoir des changements compatibles sans changer de numéro. La version 2026-07-28 correspond donc à des changements incompatibles arrêtés le 28/07/2026.
Les changements majeurs
| Avant (2025-11-25) | Maintenant (2026-07-28) |
|---|---|
Poignée de main initialize puis notifications/initialized |
Supprimée : version et capacités dans le _meta de chaque requête |
Session par connexion, en-tête Mcp-Session-Id |
Supprimés ; un état durable passe par un identifiant explicite, argument ordinaire des outils |
| Négociation au démarrage | Méthode server/discover, obligatoire côté serveur, facultative côté client |
Flux GET séparé, resources/subscribe |
Remplacés par subscriptions/listen, un flux unique pour les notifications choisies |
| Le serveur envoie ses propres requêtes (échantillonnage, élicitation, racines) | Le serveur renvoie un résultat input_required ; le client relance la requête avec les réponses |
ping, logging/setLevel |
Supprimés ; niveau de journal par requête dans _meta |
Reprise de flux SSE par Last-Event-ID |
Supprimée : un flux coupé perd la requête, à renvoyer avec un nouvel identifiant |
| Tâches expérimentales dans le cœur | Déplacées dans une extension officielle, io.modelcontextprotocol/tasks |
SSE (Server-Sent Events) désigne le flux HTTP par lequel le serveur envoie plusieurs messages sur une même réponse.
Autre changement structurant : tous les résultats portent désormais un champ resultType, "complete" pour un résultat ordinaire ou "input_required" pour un résultat intermédiaire. Un client doit traiter comme "complete" un résultat d'ancien serveur qui ne le contient pas.
Les changements mineurs à surveiller
- Les listes (
tools/list,prompts/list,resources/list,resources/read,resources/templates/list) portent des champs de cache obligatoires :ttlMs(durée de fraîcheur en millisecondes) etcacheScope("public"ou"private"). - Les requêtes HTTP POST doivent porter les en-têtes
Mcp-MethodetMcp-Name, et un paramètre d'outil peut être recopié dans un en-tête grâce àx-mcp-header. - Les serveurs devraient renvoyer leurs outils dans un ordre stable.
inputSchemaetoutputSchemaacceptent tous les mots-clés de JSON Schema 2020-12.- L'erreur « ressource introuvable » passe du code
-32002à-32602. - Côté OAuth, les serveurs d'autorisation devraient inclure le paramètre
iss, et les clients doivent le vérifier quand il est présent.
Ce qui devient déprécié
Déprécié veut dire : toujours dans la spécification, mais appelé à disparaître. Une fonction dépréciée reste au moins douze mois (quatre-vingt-dix jours en cas de retrait accéléré).
- Roots, Sampling et Logging : passez les dossiers ou fichiers en paramètres d'outil, URI de ressource ou configuration plutôt que Roots ; appelez directement l'API (interface de programmation) d'un fournisseur de modèle plutôt que Sampling ; journalisez sur stderr ou avec OpenTelemetry plutôt que Logging.
- Le transport HTTP+SSE de 2024-11-05 : migrez vers Streamable HTTP.
- L'enregistrement dynamique des clients OAuth (RFC 7591) : au profit des documents de métadonnées de client, gardé pour compatibilité.
Ce que cela change pour vous
Vous écrivez un serveur. Vérifiez que votre SDK (kit de développement) prend en charge la révision : la documentation rappelle que chaque SDK adopte les nouvelles révisions à son propre rythme. En TypeScript, le tutoriel officiel utilise serveStdio, qui répond aux clients 2026-07-28 comme à ceux qui ouvrent encore par initialize ; un serveur branché avec server.connect(new StdioServerTransport()) ne sert que les clients de l'ère 2025. Si vos outils gardaient un état lié à la session, remplacez-le par un identifiant explicite renvoyé par un outil de création et vérifié à chaque appel.
Vous écrivez un client. Ajoutez le _meta à chaque requête, gérez UnsupportedProtocolVersionError, resultType et les relances input_required, et prévoyez la détection des anciens serveurs.
Vous testez. MCP Inspector propose deux « ères » de protocole, modern et legacy : testez les deux. Voir tester un serveur avec MCP Inspector.
Pour le détail des transports, voir stdio ou Streamable HTTP ; pour l'architecture d'ensemble, comment fonctionne MCP.
Questions fréquentes
Un client récent peut-il parler à un ancien serveur MCP ?
Oui, s'il gère la rétrocompatibilité : la spécification décrit comment détecter un serveur des révisions 2025-11-25 et antérieures et revenir à la poignée de main initialize.
L'échantillonnage (sampling) est-il supprimé ?
Il est déprécié, pas supprimé : il reste fonctionnel pendant la période de dépréciation, mais les nouvelles implémentations ne devraient pas l'ajouter.
Sources
Pages consultées pour écrire cet article :