~/ / Articles sur l'IA / Spécification MCP 2026-07-28 : ce qui change, et ce qu'il faut vérifier dans vos propres fichiers
Spécification MCP 2026-07-28 : ce qui change, et ce qu'il faut vérifier dans vos propres fichiers
La révision 2026-07-28 de la spécification du Model Context Protocol (MCP) supprime les sessions au niveau du protocole, déprécie l'ancien transport HTTP+SSE ainsi que plusieurs fonctionnalités, et assouplit les règles applicables aux schémas d'outils. Cet article résume le changelog officiel et montre comment vérifier deux fichiers que vous écrivez vous-même : votre configuration MCP et vos schémas d'outils.
Publié: · Vérifié par rapport à la spécification officielle le 2026-10-24. Cet article la résume et ne la remplace pas.
Les changements les plus importants
- Les sessions au niveau du protocole et l'en-tête Mcp-Session-Id sont supprimés du transport Streamable HTTP. Un serveur qui a besoin de conserver un état entre les appels utilise des identifiants explicites (handles) qu'il crée et qu'il transmet comme des arguments d'outil ordinaires.
- MCP devient sans état : la phase d'initialisation initialize est supprimée. Chaque requête porte sa version du protocole et les capacités du client dans _meta, et une version incompatible renvoie UnsupportedProtocolVersionError.
- Les serveurs doivent implémenter un nouvel appel server/discover, qui annonce les versions du protocole qu'ils prennent en charge, leurs capacités et leur identité.
- Le point de terminaison HTTP GET et resources/subscribe sont remplacés par subscriptions/listen, un flux de réponse unique et durable pour les notifications de changement auxquelles un client s'abonne.
- Les requêtes émises par le serveur, comme roots/list, sampling/createMessage et elicitation/create, sont remplacées par un schéma Multi Round-Trip Requests : le serveur renvoie un résultat qui demande une saisie, et le client relance la requête d'origine avec ses réponses.
- Les tâches expérimentales quittent le cœur du protocole pour devenir une extension officielle.
- Les flux SSE reprenables (Last-Event-ID) sont supprimés. Un flux de réponse interrompu fait perdre la requête en cours, et le client doit la renvoyer sous la forme d'une nouvelle requête.
Ce qui est désormais déprécié
| Fonctionnalité | Dépréciée depuis | Suppression au plus tôt | Migration suggérée |
|---|---|---|---|
| Roots | 2026-07-28 | Première révision publiée à partir du 2027-07-28 | Transmettre les répertoires ou fichiers via les paramètres d'outil, les URI de ressources ou la configuration du serveur |
| Sampling | 2026-07-28 | Première révision publiée à partir du 2027-07-28 | S'intégrer directement aux API des fournisseurs de LLM |
| Logging | 2026-07-28 | Première révision publiée à partir du 2027-07-28 | Journaliser sur stderr pour stdio, ou utiliser OpenTelemetry |
| Dynamic Client Registration | 2026-07-28 | Première révision publiée à partir du 2027-07-28 | Client ID Metadata Documents |
| Transport HTTP+SSE | 2025-03-26 | Trois mois après le passage de SEP-2596 à l'état Final | Streamable HTTP |
| Valeurs thisServer et allServers de includeContext | 2025-11-25 | Suit Sampling | Omettre le champ ou utiliser none |
Une fonctionnalité dépréciée reste dans la spécification. La suppression au plus tôt indique à partir de quand elle peut être retirée, et le retrait effectif est une décision prise lors de la préparation de la version. La nouvelle politique de cycle de vie des fonctionnalités fixe une durée minimale de dépréciation de douze mois.
Vérifier votre configuration MCP
Si votre configuration utilise encore le transport HTTP+SSE, elle figure dans la liste des éléments dépréciés. La documentation de Claude Code qualifie elle aussi son type sse de déprécié et recommande d'utiliser des serveurs HTTP lorsqu'ils sont disponibles. La spécification décrit son remplaçant, Streamable HTTP : le serveur expose un unique point de terminaison qui accepte POST, et le client envoie chaque message JSON-RPC dans sa propre requête HTTP POST.
- Chaque POST doit inclure un en-tête Accept qui énumère à la fois application/json et text/event-stream.
- Chaque POST doit inclure un en-tête MCP-Protocol-Version dont la valeur correspond à la version du protocole indiquée dans le corps de la requête.
- Les requêtes portent un en-tête Mcp-Method, ainsi qu'un en-tête Mcp-Name pour tools/call, resources/read et prompts/get.
- Le serveur répond à chaque requête par un seul objet JSON ou par un flux SSE limité à cette requête.
La révision du protocole prise en charge par votre client relève de la documentation de votre client. Le vérificateur ci-dessous lit un fichier .mcp.json ou claude_desktop_config.json et signale des entrées telles qu'un serveur distant sans type, ou qui utilise encore sse.
Essayer: MCP Config Checker
Règles vérifiées au regard de la documentation le 2026-10-23.
Documentation : Claude Code / Model Context Protocol / VS Code
Non vérifié : l'existence d'une commande, l'installation d'un paquet, la réponse d'un serveur distant et les paramètres que d'autres applications interprètent différemment.
Tout s'exécute dans votre navigateur. La configuration n'est pas envoyée.
Les schémas d'outils peuvent utiliser tout JSON Schema 2020-12
- inputSchema et outputSchema acceptent désormais n'importe quel mot-clé de JSON Schema 2020-12, et structuredContent peut être n'importe quelle valeur JSON. La spécification ajoute des exigences pour la résolution de $ref et des limites sur les ressources que les mots-clés de composition peuvent utiliser.
- Un serveur peut marquer un paramètre d'outil avec x-mcp-header afin que sa valeur soit copiée dans un en-tête HTTP Mcp-Param-{name}. Le paramètre marqué doit être une chaîne, un entier ou un booléen, et non un nombre.
- La propriété marquée doit être accessible depuis la racine du schéma uniquement par des clés properties. La chaîne ne doit passer ni par items, oneOf, anyOf, allOf, not, if/then/else, ni par $ref.
- Un client qui utilise Streamable HTTP doit rejeter la définition d'un outil dont l'annotation x-mcp-header enfreint ces règles, ce qui signifie que l'outil est exclu du résultat de tools/list.
Pour tester un schéma d'outil, collez-le avec un jeu d'arguments d'exemple dans le validateur ci-dessous. Il vérifie les mots-clés courants de Draft 2020-12 et vous indique ceux qu'il ne vérifie pas.
Essayer: JSON Schema Validator
Suit JSON Schema Draft 2020-12 pour les mots-clés pris en charge. Il ne lit $ref qu'à l'intérieur du même schéma.
Tout s'exécute dans votre navigateur. Le schéma et les données ne sont pas envoyés.
Points de sécurité pour les serveurs
- Un serveur doit valider l'en-tête Origin sur toutes les connexions entrantes afin de prévenir les attaques par DNS rebinding. Si l'en-tête est présent et invalide, il doit répondre par HTTP 403 Forbidden.
- Un serveur exécuté en local doit se lier uniquement à localhost (127.0.0.1), et non à toutes les interfaces réseau (0.0.0.0).
- Les serveurs devraient mettre en œuvre une authentification adéquate pour toutes les connexions.
- Un serveur qui traite le corps de la requête doit rejeter toute requête dont les en-têtes ne correspondent pas au corps, avec HTTP 400 et l'erreur JSON-RPC HeaderMismatch (code -32020).
- Les serveurs d'autorisation devraient inclure le paramètre iss dans les réponses d'autorisation (RFC 9207), et lorsqu'un iss est présent, les clients doivent le valider avant d'échanger le code d'autorisation.
- Les clients doivent indexer les identifiants client enregistrés par l'émetteur qui les a accordés, et ne doivent pas les réutiliser avec un autre serveur d'autorisation.