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 |
1 2 3 4 5 6 7 8 | POST /mcp HTTP/1.1 MCP-Protocol-Version: 2026-07-28 Mcp-Method: tools/call Mcp-Name: search {"jsonrpc":"2.0","id":1,"method":"tools/call", "params":{"name":"search","arguments":{"q":"otters"}, "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}} |
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...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
Envoyé par Alex
