MCP 2026-07-28 : ce qui change pour vos agents IA

MCP 2026-07-28 est la release candidate de la plus grande mise à jour du Model Context Protocol depuis son lancement en novembre 2024. Architecture sans état, extensions formalisées, MCP Apps, Tasks graduées, dépréciations annoncées avec préavis de 12 mois : la spec finale sort le 28 juillet 2026 après une fenêtre de validation de 10 semaines. Voici ce qui change concrètement pour vos agents et vos serveurs.

Source :
blog.modelcontextprotocol.io
·  Publié le 21 mai 2026

MCP, une technologie née d’une frustration de développeur

Novembre 2024. David Soria Parra, ingénieur chez Anthropic, en a assez de copier le même code entre Claude Desktop et son IDE. Avec Justin Spahr-Summers, il formalise une idée simple : un protocole ouvert pour connecter les modèles d’IA aux outils et aux sources de données, une fois pour toutes. Le Model Context Protocol est lancé le 25 novembre 2024, avec les premiers SDKs Python et TypeScript.

La motivation technique derrière MCP est ce que les deux ingénieurs appellent le « problème M×N » : sans standard commun, connecter M modèles à N outils produit une explosion combinatoire de M×N intégrations sur mesure. MCP ramène ça à M+N. Un serveur MCP écrit une fois peut être consommé par n’importe quel client qui respecte la spec.

L’adoption a été rapide, très rapide. En février 2025, soit trois mois après le lancement, plus de 1 000 serveurs MCP communautaires existent déjà. En mars 2025, OpenAI adopte officiellement le protocole et l’intègre dans ChatGPT Desktop. Google DeepMind confirme le support dans Gemini. Des dizaines de plateformes suivent : GitHub, Replit, Linear, Zapier, Sourcegraph, Block…. En décembre 2025, Anthropic cède la gouvernance du protocole à l’Agentic AI Foundation (AAIF), un fonds dirigé hébergé par la Linux Foundation, co-fondé avec Block et OpenAI. En avril 2026, le premier MCP Dev Summit North America réunit 1 200 développeurs à New York. Aujourd’hui, plus de 16 000 serveurs MCP référencés circulent dans la communauté.

MCP est devenu, en moins de 18 mois, le standard de fait pour connecter les agents IA au monde extérieur. La version 2026-07-28 n’est pas une mise à jour cosmétique : c’est la première révision majeure d’un protocole que des milliers de serveurs en production utilisent tous les jours. Ce qui se joue dans cette spec, c’est la capacité de MCP à passer à l’échelle des infrastructures distribuées modernes tout en restant rétrocompatible pour les intégrateurs existants.

Qu’est-ce que cette mise à jour change au fond ?

La version 2026-07-28 est décrite par l’équipe MCP comme « la plus grande révision du protocole depuis le lancement ». Trois axes structurent la mise à jour : la suppression de la gestion de session au niveau protocole (passage à une architecture sans état), la formalisation d’un système d’extensions pour les capacités optionnelles, et un cadre de gouvernance durable avec politique de cycle de vie et conformance obligatoire.

La release candidate a été verrouillée le 21 mai 2026. La spec finale est attendue pour le 28 juillet 2026, après une fenêtre de validation de 10 semaines pendant laquelle les mainteneurs de SDK valident les changements avec des charges de travail en production. Les SDK Python et TypeScript sont mis à jour en parallèle. Pour les intégrateurs, la bonne nouvelle est que les dépréciations (Roots, Sampling, Logging) disposent d’une fenêtre de 12 mois minimum avant leur suppression effective.

Architecture sans état : vers le load balancing natif

Le changement le plus profond de la spec 2026-07-28 touche la gestion de session. Dans les versions précédentes, les clients devaient envoyer un header Mcp-Session-Id et passer par une initialisation (« handshake ») avant de pouvoir utiliser un serveur. Cette dépendance à un état partagé créait des contraintes d’infrastructure non négligeables : routage « sticky » obligatoire, stockage de session distribué, impossibilité de scaler horizontalement sans coordination.

La nouvelle spec supprime tout ça. Un appel MCP ressemble désormais à :

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call

Chaque requête est autonome. N’importe quelle instance du serveur peut la traiter. Les informations client (contexte, métadonnées) sont transmises via les champs _meta à chaque requête plutôt qu’une seule fois lors de l’initialisation de session. Côté infrastructure, ça signifie que vous pouvez mettre un load balancer standard devant votre flotte de serveurs MCP sans configuration spéciale, et scaler indépendamment chaque instance.

Deux nouveaux headers complètent ce changement : Mcp-Method et Mcp-Name. Ils permettent aux gateways et aux reverse proxies de router les requêtes MCP sans avoir à inspecter le corps JSON. Concrètement, vous pouvez router tools/call vers un pool de serveurs différent de resources/read au niveau réseau, sans parsing applicatif.

Comment les communications serveur-client sont-elles repensées ?

La version précédente de MCP utilisait les Server-Sent Events (SSE) pour les flux de données du serveur vers le client. Cette approche posait des problèmes similaires à la gestion de session : connexions persistantes difficiles à proxifier, incompatibles avec les architectures stateless, et problématiques derrière certains load balancers.

La spec 2026-07-28 remplace les SSE par un modèle de requêtes multi-round-trip. Quand un serveur a besoin d’une entrée du client (confirmation utilisateur, sélection d’option, données supplémentaires), il retourne une réponse structurée plutôt qu’une connexion persistante :

{
  "resultType": "inputRequired",
  "inputRequests": {...},
  "requestState": "..."
}

Le client reçoit cette réponse, collecte l’entrée nécessaire, et renvoie une nouvelle requête en incluant l’état (requestState) retourné par le serveur. L’état est opaque pour le client : il réalise un echo tel quel. N’importe quelle instance du serveur peut reprendre la conversation à partir de cet état. Cette approche est cohérente avec l’architecture sans état : la continuité du dialogue est portée par le client, pas par le serveur.

Le support du W3C Trace Context via les champs _meta complète ces changements : chaque requête peut transporter des identifiants de trace compatibles OpenTelemetry, ce qui permet de suivre un appel agent à travers plusieurs serveurs MCP et services externes dans un seul tracé distribué.

Le cadre d’extensions : MCP devient modulaire

L’une des limites de la spec initiale était le manque de mécanisme officiel pour les capacités optionnelles. Les équipes devaient soit attendre que la spec intègre leur besoin, soit implémenter des conventions non standardisées. La version 2026-07-28 introduit un système d’extensions formalisé.

Les extensions utilisent des identifiants reverse-DNS (style com.example.my-extension) pour éviter les conflits de nommage. Elles négocient leur activation via les maps de capacités échangées lors de la découverte. Chaque extension a son propre versioning indépendant du protocole principal, ce qui lui permet d’évoluer sans bloquer les releases MCP.

Le processus SEP (Spec Enhancement Proposal) gagne une catégorie « Standards Track » pour les extensions destinées à devenir des standards interopérables. Les extensions Standards Track doivent s’accompagner d’une suite de conformance : des scénarios de test concrets que les implémentations doivent faire passer pour revendiquer la conformité. Deux extensions inaugurales entrent directement sous ce régime.

MCP Apps et Tasks : les deux premières extensions officielles

MCP Apps permet aux serveurs d’exposer des interfaces HTML directement dans les définitions d’outils. L’hôte (Claude Desktop, un IDE, une application agentique) affiche ces interfaces dans un iframe sandbox. Toutes les interactions de l’utilisateur dans l’interface passent par le protocole JSON-RPC standard : aucun canal latéral, aucune communication directe entre l’iframe et l’extérieur. C’est une façon propre d’embarquer des UI configurables (formulaires, dashboards, visualisations) dans des agents sans sortir du modèle de sécurité MCP.

L’extension Tasks officialise ce qui était expérimental depuis plusieurs mois. Le cycle de vie est redesigné : un serveur répond à un appel d’outil avec un « task handle » plutôt qu’une réponse immédiate. Le client pilote ensuite l’exécution via tasks/get, tasks/update et tasks/cancel. La création de tâches est désormais à l’initiative du serveur (plus du client), ce qui correspond mieux aux workflows longs où le serveur sait mieux que le client quand une tâche asynchrone est nécessaire. tasks/list est supprimé : sa dépendance à l’état de session le rendait incompatible avec l’architecture stateless.

Autorisation, gouvernance et conformance

Six SEPs (=Specification Enhancement Proposal) d’autorisation renforcent l’alignement avec OAuth 2.0 et OpenID Connect. Les points clés : la validation obligatoire du paramètre iss selon la RFC 9207, la déclaration du type d’application lors de l’enregistrement dynamique de client, la liaison des credentials à leur serveur d’autorisation émetteur, et la clarification de l’accumulation de scopes lors des élévations de privilèges. Ces changements s’adressent principalement aux déploiements d’entreprise où la sécurité de la chaîne d’autorisation est critique.

Sur la gouvernance, trois mécanismes structurent la vie future du protocole. La Feature Lifecycle Policy définit un cycle en trois étapes : Active, Deprecated (avec annonce publique et migration documentée), puis Removed (après 12 mois minimum). Ce préavis de 12 mois est une garantie explicite pour les intégrateurs. Le cadre d’extensions permet aux capacités optionnelles de mûrir indépendamment. Les SEPs Standards Track nécessitent désormais une suite de conformance : un serveur ou client MCP ne peut pas revendiquer la conformité à une extension sans faire passer ses scénarios de test.

Quelles fonctionnalités disparaissent, et pourquoi ?

Trois capacités passent en statut « deprecated » avec la spec 2026-07-28 :

• Roots : remplacé par les paramètres d’outils ou les URI de ressources. La notion de « racine » du contexte était floue et rarement utilisée de façon cohérente entre les implémentations.
• Sampling : le mécanisme permettant à un serveur MCP de déclencher des appels LLM via le client est déprécié. La recommandation est d’appeler directement l’API du fournisseur LLM depuis le serveur. Cette décision reflète une séparation plus nette des responsabilités : MCP gère la communication outil/modèle, pas la génération elle-même.
• Logging : remplacé par stderr ou OpenTelemetry. Les logs MCP-natifs créaient une dépendance à l’état de session et doublonnaient avec les solutions d’observabilité standard.

La suppression effective interviendra au plus tôt 12 mois après la publication de la spec finale, soit pas avant juillet 2027. Le temps de migrer vos implémentations.

JSON Schema 2020-12 : des définitions d’outils plus expressives

Les schémas d’outils MCP supportaient jusqu’ici un sous-ensemble limité de JSON Schema. La spec 2026-07-28 passe à JSON Schema 2020-12 complet : opérateurs de composition (oneOf, anyOf, allOf), schémas conditionnels (if/then/else), références et définitions ($ref, $defs). Les schémas de sortie d’outil ne sont plus contraints non plus.

Cela ouvre des possibilités concrètes : un outil peut maintenant déclarer que ses paramètres d’entrée sont mutuellement exclusifs (oneOf), que certains champs ne sont obligatoires que sous certaines conditions (schémas conditionnels), ou réutiliser des définitions de types complexes à travers plusieurs outils via $ref. Pour les développeurs qui construisent des outils avec des types de données riches, c’est une amélioration significative.

Un breaking change mineur à noter : les erreurs de ressource manquante changent de code JSON-RPC, de -32002 à -32602 (paramètre invalide standard). Si votre code teste explicitement ce code d’erreur, il faudra le mettre à jour.

FAQ

Mes agents vont-ils continuer à fonctionner avec des serveurs MCP version antérieure ?

Si vos agents utilisent un client MCP à jour qui supporte 2026-07-28, ils peuvent toujours communiquer avec des serveurs qui implémentent des versions antérieures (comme 2024-11-05). La négociation de version se fait via le header MCP-Protocol-Version : le client annonce sa version, le serveur répond avec la version qu’il supporte. Les deux parties descendent à la version commune la plus haute qu’elles partagent. Cette rétrocompatibilité est intentionnelle et documentée dans la spec.

Le vrai risque de rupture concerne les fonctionnalités dépréciées. Si votre code agent dépend de Sampling ou de Roots, vous avez jusqu’à juillet 2027 (au plus tôt) pour migrer. Les serveurs qui n’ont pas encore migré vers 2026-07-28 continueront à exposer ces capacités normalement.

Un serveur MCP pourra-t-il exposer les deux versions de la spec simultanément ?

La spec ne l’interdit pas, mais ce n’est pas le modèle recommandé. L’approche standard est qu’un serveur déclare les versions qu’il supporte dans sa réponse de capabilities. Un client qui comprend 2026-07-28 peut alors choisir de dégrader vers 2024-11-05 si le serveur ne supporte pas encore la nouvelle version.

Pour les intégrateurs qui veulent migrer progressivement, le chemin le plus propre est de déployer la nouvelle version du SDK (qui gère la négociation de version automatiquement) et de valider que vos handlers restent compatibles. La suppression des sessions et des SSE est le changement qui nécessite le plus d’attention : si votre serveur utilisait l’état de session pour suivre des conversations multi-tours, vous devrez refactoriser cette logique pour la porter côté client via requestState.

MCP Apps : est-ce une réponse aux interfaces conversationnelles dans les agents ?

En partie. MCP Apps résout un problème concret : les outils MCP ne pouvaient jusqu’ici exposer que des données structurées (JSON). Pour les outils qui bénéficient d’une interface visuelle (configuration complexe, visualisation de résultats, sélection dans une liste longue), les développeurs devaient soit tout passer en paramètres textuels, soit sortir du cadre MCP. L’extension permet désormais d’embarquer une UI minimale directement dans la définition de l’outil, tout en gardant la sandbox de sécurité MCP.

Sampling est déprécié : comment remplacer ce comportement ?

Sampling permettait à un serveur MCP de demander au client de faire un appel LLM en son nom, puis de recevoir la réponse. La recommandation de remplacement est d’appeler directement l’API du fournisseur LLM depuis le serveur. Si votre serveur a besoin de génération LLM, il doit gérer sa propre clé API et ses propres appels, indépendamment du client MCP. C’est une séparation plus nette architecturalement, mais elle requiert que le serveur ait accès aux credentials LLM, ce qui implique une revue de votre modèle de sécurité.

Lire l’annonce complète →

Conclusion

La spec 2026-07-28 est la preuve que MCP a réussi son pari initial : assez d’adoption pour que ses limites d’architecture deviennent visibles en production. Le passage à une architecture sans état n’est pas un choix idéologique, c’est une réponse directe aux contraintes que des milliers de déploiements ont remontées. Le cadre d’extensions prépare MCP à grandir sans que chaque nouvelle capacité passe par un vote de l’ensemble des mainteneurs. Les prochains 18 mois verront probablement une prolifération d’extensions Standards Track autour de l’observabilité, de la sécurité multi-tenant et des capacités audio/vidéo. MCP n’est plus un protocole expérimental : c’est une infrastructure.

Pour aller plus loin, notre revue de presse sur MCP et l’IA agentique couvrait en mai 2026 comment MCP s’impose en standard d’ingénierie de contexte.