MCP 2026-07-28 : ce qui change et comment réussir la migration

La spécification stable MCP datée du 28 juillet 2026 revoit plusieurs fondations du protocole Model Context Protocol. Sessions protocolaires supprimées, découverte explicite des capacités, nouveau mécanisme d’écoute, réponses serveur encadrées et extensions séparées du cœur : une migration sérieuse demande davantage qu’un changement de version dans un gestionnaire de paquets. Voici ce qui change, ce qui reste vrai et la méthode la plus sûre pour faire évoluer un client ou un serveur MCP.

Publié le 2 août 2026. Analyse fondée sur la spécification MCP 2026-07-28 et les notes de version officielles disponibles à cette date.

Une version stable, mais une vraie rupture de protocole

MCP standardise la manière dont une application d’intelligence artificielle échange avec des outils et des ressources. Il ne fournit ni modèle, ni agent autonome, ni politique de sécurité prête à l’emploi. Pour replacer cette mise à jour dans son architecture générale, consultez le guide Promptique des agents IA et de MCP.

Le libellé 2026-07-28 désigne une révision du protocole. Il ne signifie pas que tous les SDK portent le même numéro. Le SDK Python officiel a, par exemple, publié une version 2.0.0, le SDK C# une version 2.0.0 et le SDK Go une version 1.7.0 le même jour. Chaque écosystème conserve son propre versionnage.

Autre nuance importante : la publication d’une spécification stable n’oblige pas chaque produit compatible MCP à la prendre en charge immédiatement. Un client peut rester sur une ancienne révision, un serveur peut en accepter plusieurs et un intermédiaire peut encore dépendre d’anciens comportements. La compatibilité réelle doit donc être vérifiée entre les composants effectivement déployés.

Sujet	Avant ou usage historique	Révision 2026-07-28	Action pratique
Négociation	initialize puis initialized	Version et capacités dans les métadonnées de requête	Centraliser la création et la validation de ces métadonnées
Découverte	Informations obtenues pendant l’initialisation	server/discover	Mettre en cache avec une durée et une portée explicites
Session	En-tête Mcp-Session-Id	Protocole sans session	Sortir l’état métier implicite de la couche protocolaire
Écoute	GET persistant et abonnements de ressources	subscriptions/listen	Adapter transport, reprise et annulation
Réponses serveur	Requêtes serveur vers client plus libres	MRTR, réponses liées à une requête	Revoir corrélation, délais et erreurs
Fonctionnalités	Tasks dans le cœur	Tasks sous forme d’extension	Négocier et activer explicitement l’extension

Le protocole devient sans session

La fin de l’initialisation ne supprime pas tout état

Dans la nouvelle révision, chaque requête transporte les éléments nécessaires pour identifier la version et les capacités applicables. L’échange ne dépend donc plus d’une cérémonie d’initialisation durable. Cette évolution facilite les architectures distribuées, les redémarrages et le passage par des intermédiaires qui ne garantissent pas l’affinité avec une instance précise.

Fait officiel : la révision supprime initialize, initialized et Mcp-Session-Id. Conséquence d’architecture : cela ne rend pas votre application sans état. Un panier, une autorisation en attente, une tâche longue ou la progression d’un workflow restent des états métier. Ils doivent simplement être portés par un identifiant explicite, un stockage adapté et des règles de durée de vie, au lieu d’être confondus avec une session MCP implicite.

Découverte, cache et métadonnées

La méthode server/discover fournit les informations nécessaires sur le serveur. Les indications ttlMs et cacheScope donnent un cadre au cache. En pratique, un client doit savoir quand réutiliser une découverte, quand la renouveler et à quelle identité ou portée l’associer. Une découverte mise en cache sans tenir compte de son périmètre peut exposer des capacités destinées à un autre contexte.

La présence d’un resultType obligatoire rend aussi les réponses plus explicites. Cette contrainte améliore le routage et la validation, à condition de vérifier le type avant de traiter le contenu. Pour concevoir les schémas et les sorties d’outils avec davantage de rigueur, le guide complet du prompt engineering détaille le rôle des contrats de sortie et de la validation côté application.

Transport, écoute et réponses serveur

Le transport HTTP avec SSE historique est déprécié. Le nouveau mécanisme subscriptions/listen remplace le GET persistant et les abonnements de ressources utilisés dans les révisions antérieures. Le changement concerne la connexion, mais aussi la gestion des délais, de l’annulation, de la reprise après coupure et de la pression exercée par un flux rapide sur un client lent.

La spécification introduit également MRTR pour encadrer les réponses initiées par le serveur dans le contexte d’une requête. L’objectif est de mieux corréler les échanges et d’éviter des canaux bidirectionnels ambigus. Les bibliothèques et journaux doivent conserver les identifiants utiles pour reconstruire la chaîne : demande initiale, réponse liée, résultat d’outil, erreur ou annulation.

Tasks, Roots, Sampling et Logging : lire les statuts correctement

Tasks sort du protocole central et devient une extension. Cette séparation permet au cœur de rester plus réduit, mais elle interdit de supposer que la fonction est disponible. Le client et le serveur doivent connaître l’extension et convenir de son usage. La note du SDK Python 2.0.0 précise d’ailleurs que l’extension Tasks n’y est pas incluse à cette date.

Roots, Sampling et Logging sont annoncés comme dépréciés dans la nouvelle révision. Ils ne disparaissent pas rétroactivement des révisions antérieures. Une organisation qui en dépend doit inventorier les usages, suivre la trajectoire des extensions ou solutions de remplacement et maintenir un chemin compatible tant que ses clients et serveurs n’ont pas migré.

Sécurité et OAuth : la migration doit rester restrictive

La révision renforce la manière de caractériser l’émetteur OAuth et le type d’application. Ce point mérite des tests avec le fournisseur d’identité, les proxys et les redirections réellement utilisés. Une validation qui fonctionne en local peut échouer derrière un reverse proxy, ou accepter un émetteur trop large si les contrôles ont été assouplis pour résoudre rapidement un problème de migration.

Recommandation Promptique, et non exigence textuelle de la spécification : profitez de la migration pour réduire les portées, séparer les identités de service, rendre les secrets éphémères lorsque c’est possible et exiger une approbation humaine avant une action irréversible. MCP transporte une demande d’outil, mais votre application reste responsable de l’autorisation, de la validation des arguments et de l’exécution.

Ces contrôles s’intègrent dans une gouvernance plus large. Le guide Promptique sur l’IA générative en entreprise, le RGPD et l’AI Act aide à relier permissions techniques, données personnelles, responsabilités et supervision humaine.

Un plan de migration en quatre étapes

1. Cartographier sans modifier

Recensez les clients, serveurs, passerelles, SDK et versions négociées. Recherchez les dépendances à initialize, à Mcp-Session-Id, au GET persistant, aux abonnements de ressources, à Tasks, Roots, Sampling et Logging. Ajoutez les proxys, fournisseurs OAuth et mécanismes de cache : ils font partie du chemin réel.

2. Isoler les différences de version

Placez la négociation, les métadonnées, les en-têtes et le transport derrière des adaptateurs. Le code métier ne devrait pas avoir à savoir si un appel vient de 2025-11-25 ou de 2026-07-28. Cette séparation limite les régressions et permet un retour contrôlé si un partenaire n’est pas prêt.

3. Tester les deux ères

Construisez une matrice client-serveur : nouveau vers nouveau, ancien vers ancien, puis chaque combinaison mixte officiellement prise en charge. Vérifiez le succès, mais aussi les versions inconnues, capacités absentes, résultats de type inattendu, coupures réseau, expirations de cache, annulations et refus OAuth.

4. Déployer avec observation et retour possible

Activez d’abord la nouvelle révision sur un périmètre réduit. Suivez erreurs par version, latence de découverte, connexions d’écoute, refus d’autorisation, résultats invalides et taux de retour sur le chemin ancien. N’abandonnez la compatibilité précédente qu’après mesure des clients réellement actifs.

Checklist avant la mise en production

• Version MCP négociée et journalisée pour chaque échange.
• Métadonnées de version et de capacités validées côté client et serveur.
• Aucun état métier critique ne dépend de Mcp-Session-Id.
• server/discover testé avec expiration et portée du cache.
• resultType contrôlé avant le traitement du résultat.
• subscriptions/listen testé sur coupure, reprise, annulation et client lent.
• Extensions activées uniquement après négociation explicite.
• Émetteur OAuth, type d’application, audiences et redirections vérifiés en environnement réel.
• Permissions minimales, validation des arguments et approbation des actions sensibles conservées.
• Tests croisés avec 2025-11-25 et procédure de retour documentée.

Ce que cette version stable ne garantit pas

La conformité au format MCP ne garantit ni la qualité d’un outil, ni l’exactitude d’une réponse, ni la sécurité d’une action. Elle ne remplace pas les contrôles d’accès, la validation métier, la journalisation, les limites de coût ou l’évaluation des comportements d’un agent. Elle ne prouve pas non plus qu’un client donné prend déjà en charge la nouvelle révision.

Enfin, les SDK officiels n’offrent pas tous exactement les mêmes fonctions au même moment. Lisez les notes de version du langage utilisé et épinglez la dépendance si votre application n’est pas prête. Pour Python, la branche 2.x est désormais installée par défaut avec pip install mcp selon l’annonce officielle, tandis que la branche 1.x reste en maintenance. Une contrainte <2 peut éviter une migration involontaire, mais elle doit rester temporaire et documentée.

FAQ

Faut-il migrer tous les serveurs MCP immédiatement ?

Non. Commencez par vérifier les révisions prises en charge par vos clients et dépendances. Une transition avec compatibilité double est souvent plus sûre qu’une bascule simultanée.

MCP 2026-07-28 rend-il les agents sans état ?

Non. Le protocole devient sans session, mais l’application peut conserver un état métier explicite, persistant et correctement autorisé.

Une fonctionnalité dépréciée cesse-t-elle de fonctionner ?

Pas nécessairement. La dépréciation annonce une trajectoire et invite à préparer une alternative. Le comportement dépend toujours de la révision négociée et de l’implémentation.

Tasks fait-il encore partie de MCP ?

Tasks appartient désormais à une extension, pas au cœur de la révision. Sa disponibilité doit être vérifiée et négociée séparément.

Sources officielles

• Model Context Protocol, publication de la révision 2026-07-28, 28 juillet 2026.
• Changelog officiel MCP 2026-07-28.
• Spécification officielle MCP 2026-07-28.
• SDK Python MCP 2.0.0, 28 juillet 2026.
• SDK C# MCP 2.0.0, 28 juillet 2026.
• SDK Go MCP 1.7.0, 28 juillet 2026.