Le protocole MCP (Model Context Protocol) a connu sa plus importante mise à jour depuis son lancement
Le protocole MCP (Model Context Protocol), norme open source régissant les interactions entre les systèmes d'IA, a connu sa plus importante mise à jour depuis son lancement
Le Model Context Protocol (MCP), une norme open source définissant la manière dont les systèmes d’IA interagissent avec des outils et des sources de données externes, a connu sa plus importante mise à jour depuis son lancement. Il convient notamment de noter que le cœur du protocole MCP est désormais sans état, ce qui signifie que les requêtes ne dépendent plus d’une session liée à une instance de serveur spécifique. Une nouvelle politique de dépréciation garantit également un délai d’au moins 12 mois entre la date à laquelle la dépréciation officielle d’une fonctionnalité est prononcée et celle à laquelle elle peut effectivement être supprimée — à l’exception, dans des cas très limités, des mises à jour de sécurité critiques.
Le Model Context Protocol (MCP) est une norme ouverte et un cadre open source lancé par Anthropic en novembre 2024 afin de normaliser la manière dont les systèmes d’intelligence artificielle (IA), tels que les grands modèles de langage (LLM), s’intègrent et partagent des données avec des outils, des systèmes et des sources de données externes.[1] Le MCP fournit une interface normalisée pour lire des fichiers, exécuter des fonctions et traiter des invites contextuelles. Suite à son annonce, le protocole a été adopté par les principaux fournisseurs d’IA, notamment OpenAI et Google DeepMind.
Récemment, le Model Context Protocol (MCP), une norme open source définissant la manière dont les systèmes d’IA interagissent avec des outils et des sources de données externes, a connu sa plus importante mise à jour depuis son lancement. Il convient notamment de noter que le cœur du protocole MCP est désormais sans état, ce qui signifie que les requêtes ne dépendent plus d’une session liée à une instance de serveur spécifique. Ce changement pourrait permettre de lever les obstacles de longue date à l’évolutivité.
L'annonce de la spécification, rédigé par les principaux responsables de la maintenance, David Soria Parra et Den Delimarsky (qui travaillent tous deux chez Anthropic), indique : « Le point fort de cette version est un cœur de protocole sans état : le MCP passe d’un protocole bidirectionnel avec état à un protocole sans état de type requête/réponse. Il s’agissait de l’une des fonctionnalités les plus demandées par les développeurs, qui souhaitaient vivement bénéficier d’une meilleure fiabilité et d’une meilleure évolutivité pour leurs serveurs MCP. »
Une nouvelle politique de dépréciation garantit également un délai d’au moins 12 mois entre la date à laquelle la dépréciation officielle d’une fonctionnalité est prononcée et celle à laquelle elle peut effectivement être supprimée — à l’exception, dans des cas très limités, des mises à jour de sécurité critiques. Cela s’inscrit une nouvelle fois dans la logique générale de la nouvelle spécification, qui vise à « améliorer le fonctionnement à l’échelle de l’entreprise ».
Cette mise à jour est « la plus importante pour MCP depuis le lancement de MCP à distance il y a plus d’un an », a écrit Soria Parra. Parmi les autres nouveautés, on peut citer « les requêtes à allers-retours multiples, le routage basé sur les en-têtes, les résultats de listes pouvant être mis en cache, le renforcement de l’autorisation, un cadre d’extensions formel et des SDK de niveau 1 mis à jour ».
Voici l'annonce de la mise à jour :
Spécification du 28 juillet 2026
La spécification du protocole Model Context Protocol (MCP) du 28 juillet 2026 est désormais disponible. Elle intègre un cœur de protocole sans état, des requêtes à allers-retours multiples, un routage basé sur les en-têtes, des résultats de liste pouvant être mis en cache, un renforcement de l’autorisation, un cadre formel pour les extensions, ainsi que des SDK de niveau 1 mis à jour.
Depuis notre dernière version publiée en novembre, le MCP a continué à se développer à un rythme effréné. Sur l’ensemble de nos SDK de niveau 1, nous enregistrons près d’un demi-milliard de téléchargements par mois, les SDK TypeScript et Python ayant tous deux franchi le seuil du milliard de téléchargements au total. En l’espace de quelques mois seulement, le protocole a poursuivi son développement en tant que substrat de données et d’interactivité pour les workflows agentiques.
Aujourd’hui, nous lançons officiellement la prochaine version de la spécification MCP, 2026-07-28, ainsi que les SDK qui vous permettront de commencer immédiatement à développer des clients et des serveurs.
Le point fort de cette version est un cœur de protocole sans état : le MCP passe d’un protocole bidirectionnel avec état à un protocole sans état de type requête/réponse. Il s’agissait de l’une des fonctionnalités les plus demandées par les développeurs, qui souhaitaient bénéficier d’une meilleure fiabilité et d’une meilleure évolutivité pour leurs serveurs MCP.
Une brève démonstration du cœur de protocole sans état en action.
Bien sûr, cette version apporte bien d’autres nouveautés :
- Chaque requête est auto-descriptive, avec un appel de découverte facultatif pour les clients souhaitant connaître les capacités à l’avance ; ainsi, toute requête peut aboutir sur n’importe quelle instance derrière un simple équilibreur de charge de type round-robin.
- Les noms de méthodes et d’outils sont transmis dans les en-têtes HTTP Mcp-Method et Mcp-Name, ce qui permet aux passerelles d’acheminer et d’autoriser directement en fonction des en-têtes.
- Les requêtes serveur-client pour des opérations telles que l’échantillonnage et l’élicitation sont repensées pour utiliser les requêtes à allers-retours multiples (MRTR), ce qui supprime la nécessité de flux bidirectionnels ouverts en permanence.
- Les réponses de liste contiennent des indications de mise en cache et un ordre déterministe, ce qui permet aux clients de mettre en cache les catalogues d’outils et de maintenir la stabilité des caches d’invites en amont lors des reconnexions.
- Adoption officielle d’un cadre d’extensions approprié, les « Tasks » venant s’ajouter à d’autres extensions telles que les applications MCP et l’autorisation gérée en entreprise (EMA).
- Une série de modifications visant à renforcer l’autorisation, notamment la validation de l’émetteur selon la RFC 9207 et l’abandon officiel de l’enregistrement dynamique des clients (DCR) au profit des documents de métadonnées client (CIMD).
- Une politique officielle de dépréciation prévoyant un délai minimum de douze mois, afin que vous puissiez planifier vos mises à niveau plutôt que de devoir y réagir.
Les SDK TypeScript, Python, Go et C# sont mis à jour en conséquence, avec des notes de migration détaillées concernant les éléments incompatibles — et vous pouvez commencer à utiliser la nouvelle spécification dès maintenant.
Ce qui a changé
Plus de handshake ni de sessions
Avec cette nouvelle version de la spécification, nous avons officiellement supprimé l’échange initialize/initialized ainsi que l’en-tête Mcp-Session-Id. Chaque requête circule désormais de manière autonome, en transportant sa version de protocole, l’identité du client et ses capacités dans _meta. Si un client souhaite connaître les capacités d’un serveur avant toute autre action, il existe désormais un nouvel appel de procédure à distance (RPC) server/discover prévu à cet effet ; toutefois, celui-ci n’est pas obligatoire. Toute requête peut désormais aboutir sur n’importe quelle instance de serveur derrière un équilibreur de charge simple de type « round-robin », sans nécessiter de stockage partagé.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
La suppression de la session au niveau du protocole n’oblige pas votre application à être sans état. Si votre serveur a besoin de conserver l’état d’une requête à l’autre, générez un identifiant explicite à partir d’un outil et demandez au modèle de le renvoyer en tant qu’argument. Nous avons constaté que cela fonctionne mieux qu’un état de session masqué dans le transport : le modèle peut voir le descripteur et le transmettre d’un outil à l’autre.
Requêtes à allers-retours multiples (MRTR)
Les requêtes MRTR remplacent les requêtes elicitation/create, sampling/createMessage et roots/list initiées par le serveur, qui nécessitaient auparavant un flux maintenu ouvert.
Il arrive parfois qu’un outil ait besoin d’une information de la part de l’utilisateur en cours d’appel, comme une confirmation ou un paramètre manquant. Le MRTR permet de gérer ce scénario via un protocole sans état : le serveur renvoie `resultType: "input_required" avec les requêtes auxquelles il attend une réponse, et le client réitère l’appel d’origine en joignant les réponses dans inputResponses.
Routage basé sur les en-têtes
Les requêtes HTTP streamables doivent désormais inclure les en-têtes Mcp-Method et Mcp-Name. Votre passerelle, votre limiteur de débit ou votre WAF peut ainsi acheminer et mesurer le trafic en fonction de ces en-têtes, sans avoir à analyser les corps JSON.
Les résultats des listes sont mise en cache
Les réponses provenant de tools/list, prompts/list, resources/list et resources/read comportent désormais les champs ttlMs et cacheScope. Cela permet aux clients de déterminer la meilleure stratégie de mise en cache pour les réponses et de réduire les récupérations inutiles.
Autorisation
D’après les discussions que nous avons eues avec les développeurs au cours de l’année écoulée, l’autorisation est le domaine dans lequel ils consacrent la majeure partie de leur temps d’intégration. Avec cette révision de la spécification, nous avons continué à faire évoluer l’authentification MCP et le dispositif de sécurité.
- Les serveurs d’autorisation doivent renvoyer le paramètre iss conformément à la RFC 9207, et les clients doivent le valider avant d’utiliser un code. Cela permet de combler une faille liée à une confusion au niveau du serveur d’autorisation.
- Les clients définissent le paramètre application_type lors de l’enregistrement dynamique des clients (DCR) ; ainsi, les serveurs d’autorisation ne rejettent plus les redirections vers localhost pour les applications de bureau et les applications CLI. Si vous vous êtes déjà demandé pourquoi le flux OAuth de votre client CLI générait une erreur redirect_uri, c’est probablement la raison. Et bien que nous passions progressivement aux documents de métadonnées d’identifiant client (CIMD) comme norme, il s’agit d’une mesure de renforcement visant à rendre le protocole conforme aux exigences de la spécification OAuth.
- Les identifiants client sont liés à l’émetteur qui les a créés. Aucune réutilisation n’est autorisée entre les serveurs d’autorisation.
- L’enregistrement dynamique des clients (DCR) est désormais officiellement déprécié au profit des CIMD. Le DCR continue de fonctionner à des fins de rétrocompatibilité, mais sera supprimé dans une future version de la spécification MCP.
Tâches
Les tâches quittent le noyau expérimental pour rejoindre l’extension io.modelcontextprotocol/tasks, avec une méthode tasks/get basée sur l’interrogation et une nouvelle méthode tasks/update. Les notifications de modification passent de l’ancien point de terminaison HTTP GET à un flux unique subscriptions/listen auquel les clients s’abonnent par type de notification.
Fonctionnalités obsolètes
Les fonctionnalités « Roots », « Sampling » et « Logging » sont obsolètes. Elles fonctionnent toujours et continueront de fonctionner pendant au moins douze mois. Les nouvelles implémentations ne doivent pas les adopter. Le transport HTTP+SSE hérité est également considéré comme officiellement obsolète, avec une période de transition d’un an.
SDK
À ce jour, les quatre SDK de niveau 1 prennent en charge la version 2026-07-28 :
- TypeScript
- Python
- Go
- C#
Au-delà de cette liste de niveau 1, le SDK Rust prend en charge la nouvelle spécification en version bêta.
Ces SDK implémentent des API qui vous permettent de développer à la fois des serveurs et des clients avec la nouvelle version de la spécification. Comme nous l’avons mentionné dans l’article de blog consacré à la version bêta des SDK, la migration entraînera certains coûts, en particulier pour les développeurs qui s’appuyaient sur des identifiants de session ; cependant, nous avons intégré les retours issus des premiers tests, ce qui facilite considérablement ce processus.
Prise en charge par l’écosystème
Comme pour toute version majeure, le travail que nous menons avec MCP ne serait pas possible sans les contributions des acteurs de l’écosystème. Nous sommes également particulièrement reconnaissants envers un certain nombre de contributeurs et de partenaires qui nous ont aidés à tester et à valider la spécification avant sa mise à disposition générale.
Source : Annonce de la mise à jour MCP
Et vous ?
Pensez-vous que cette mise à jour est crédible ou pertinente ?
Voir aussi :
Répondre avec citation
Partager