Les mainteneurs du Model Context Protocol ont publié le 22 août une nouvelle feuille de route pour les six à douze prochains mois. MCP veut notamment mieux identifier les agents, unifier ses transports autour de HTTP et rendre les longues tâches asynchrones plus cohérentes.
Le document ne promet pas un calendrier de livraison ferme. Il fixe les sujets auxquels les mainteneurs donneront la priorité lors de l’examen des propositions d’évolution, appelées SEP. Pour les développeurs d’agents et de serveurs MCP, il dessine néanmoins assez clairement la direction technique du protocole.
Donner une identité propre aux agents
L’un des chantiers les plus concrets concerne l’autorisation. Le modèle courant suppose souvent qu’un utilisateur ouvre un navigateur et donne son consentement. Cette hypothèse tient moins bien lorsqu’un agent fonctionne dans le cloud, agit au nom d’une personne absente ou crée des sous-agents qui ne devraient recevoir qu’une partie de ses droits.
La feuille de route prévoit un groupe de travail dédié à l’identité des agents. Les mainteneurs citent la fédération d’identité de charge de travail, l’échange de jetons défini par la RFC 8693 et un mécanisme de délégation. Ils veulent aussi finaliser l’usage de DPoP, qui lie un jeton à une preuve cryptographique afin de limiter sa réutilisation frauduleuse.
L’enjeu est opérationnel : remplacer progressivement les clés copiées à la main et les jetons de longue durée par des identités plus courtes, mieux délimitées et auditables. Le texte évoque également l’attestation de présence humaine pour distinguer un client interactif d’un agent sans supervision.
Faire converger HTTP et les processus locaux
MCP possède aujourd’hui des chemins différents pour les serveurs distants en HTTP et les serveurs locaux reliés par les entrées et sorties standard. Cette séparation oblige les SDK à maintenir deux chaînes de transport et peut dupliquer certaines métadonnées.
Les mainteneurs proposent d’explorer « HTTP over stdio » : le même modèle HTTP, potentiellement en HTTP/2, circulerait aussi entre un client et un sous-processus local. Ils veulent en parallèle étendre la mise en cache avec des ETags, harmoniser les erreurs et mieux encadrer les capacités exposées par les serveurs.
Des tâches longues et des outils découverts à la demande
La feuille de route cherche également à rapprocher plusieurs briques asynchrones. Les tâches, les abonnements et les notifications de progression doivent partager un cycle de vie, une annulation et une surface d’erreur cohérents. Des événements initiés par le serveur, y compris via webhook, permettraient d’éviter qu’un client interroge continuellement un travail qui dure plusieurs minutes.
Autre priorité : la découverte progressive. Au lieu d’ingérer dès le départ tout le catalogue d’outils et de ressources d’un serveur, un client pourrait apprendre ce qui existe au fil de ses besoins. Cette approche vise les déploiements où les catalogues deviennent trop volumineux pour être transmis et placés systématiquement dans le contexte d’un modèle.
Enfin, MCP veut clarifier la forme des résultats de tools/call, améliorer les annotations et expérimenter la génération de SDK et d’exemples à partir de la spécification. Le document reste une orientation, mais il déplace nettement le centre de gravité vers des agents durables, identifiables et exploitables en entreprise.
Source : feuille de route officielle du Model Context Protocol, mise à jour le 22 août 2026.
