MCP dévoile une nouvelle feuille de route — et Hermes est déjà sur la nouvelle spécification

Le mois dernier, vous avez passé un après-midi à brancher quelques outils internes sur MCP (Model Context Protocol, le standard de facto pour connecter les applications IA à des systèmes et données externes). Serveurs configurés un par un, permissions réglées, tout fonctionne. Et cette semaine, vous voyez la nouvelle : MCP annonce une feuille de route — « sessions de protocole supprimées », « requêtes initiées par le serveur remplacées ». Votre premier réflexe est probablement : encore une migration ? Respirez. Cet article décortique ce que dit vraiment la feuille de route officielle publiée le 22 août, quels changements sont déjà arrivés avec la spécification 2026-07-28, et pourquoi les utilisateurs de Hermes sont déjà dans le nouveau train.

Ce que MCP a annoncé : une feuille de route à cinq priorités

Le 22 août, les deux mainteneurs principaux de MCP — David Soria Parra et Den Delimarsky — ont publié le billet officiel The New MCP Roadmap, avec la mise à jour correspondante sur la page feuille de route. C’est la suite formelle de la feuille de route de mars (évolution des transports, communication des agents, maturation de la gouvernance, préparation entreprise) : l’essentiel du travail des cinq derniers mois est déjà arrivé dans la spécification 2026-07-28, et la nouvelle feuille de route concentre la suite en cinq axes prioritaires :

  1. Primitives de messagerie agente : les charges de travail modernes ne tiennent plus dans le schéma requête-réponse. La feuille de route veut faire entrer Tasks (opérations asynchrones de longue durée) dans le corps de la spécification, plus des événements initiés par le serveur (webhooks et canaux, pour que les clients n’aient pas à sonder les résultats), subscriptions/listen et les notifications de progression.
  2. Unification et durcissement du transport HTTP natif : depuis 2026-07-28, un serveur MCP distant est « comme n’importe quelle charge HTTP » — vos load balancers, le serverless scale-to-zero et les health checks s’appliquent. Prochaine étape : unifier les serveurs locaux sur Streamable HTTP par-dessus stdio.
  3. Identité d’agent et sécurité entreprise : l’autorisation MCP suppose aujourd’hui qu’une personne approuve dans le navigateur, mais de plus en plus d’appelants sont des workloads cloud sans humain présent. La feuille de route vise DPoP (RFC 9449 Proof of Possession), Workload Identity Federation, l’échange standard de tokens, avec une participation continue aux groupes de travail IETF OAuth et WIMSE.
  4. Primitives améliorées : les réponses de tools/call devraient porter un contrat clair plutôt que plusieurs formes ; et pour que le modèle ne paie pas un catalogue de cent outils avant qu’une seule question soit posée, un effort de découverte progressive permet au serveur d’offrir une petite entrée et d’en révéler plus au fil de la conversation.
  5. Meilleure expérience développeur des SDK : ergonomie et conformité dans tous les SDK officiels.

Un effet pratique : les SEP qui tombent dans ces axes bénéficient d’une revue accélérée. Si vous envisagez une proposition, c’est la carte à suivre.

Ce qui est déjà arrivé avec la spécification 2026-07-28 : quatre grands changements

La feuille de route dit que « l’essentiel des changements est arrivé avec la release 2026-07-28 ». Quoi exactement, pour un développeur en activité ?

1. Le protocole est devenu sans état. Avec SEP-2575 (Stateless MCP) et SEP-2567 (Sessionless MCP), la session au niveau protocole et le handshake d’initialisation ont disparu. Un serveur MCP distant est maintenant un service HTTP comme un autre : équilibrez sans sticky sessions, scalez à zéro si vous voulez. Si votre serveur a besoin d’état entre les appels, frappez un handle explicite depuis un outil et faites-le repasser comme argument — plus transparent que des sessions cachées dans le transport.

2. MRTR a remplacé les requêtes initiées par le serveur. Dans l’ancienne spécification, les serveurs pouvaient rappeler le client (par exemple pour confirmer un paramètre) — inconfortable en déploiement sans état et derrière les pare-feu d’entreprise. Le modèle Multi Round-Trip Requests (SEP-2322) fonctionne ainsi : le serveur renvoie resultType: "input_required" avec les requêtes qu’il doit voir répondre, et le client réessaie l’appel d’origine avec les réponses attachées dans inputResponses. Elicitation, sampling et roots ont migré vers ce modèle.

3. Découverte et cache. Un client peut appeler server/discover pour connaître les versions et capacités supportées avant de se connecter ; les résultats de listes portent des indices de cache et un ordre déterministe (SEP-2549), donc les clients peuvent mettre en cache les catalogues d’outils et les caches de prompt en amont restent stables entre reconnexions.

4. Routage par en-têtes et durcissement de l’autorisation. Les noms de méthode et d’outil voyagent dans les en-têtes HTTP Mcp-Method et Mcp-Name, donc les gateways peuvent router et autoriser sur les seuls en-têtes ; l’autorisation a gagné la validation d’issuer, les credentials client liés à l’issuer et les Client ID Metadata Documents (CIMD), avec Enterprise-Managed Authorization devenue une extension stable. AWS a déjà fait atterrir Tasks dans Bedrock AgentCore, et l’Agents SDK de Cloudflare supporte la spécification dès le premier jour — c’est de l’infrastructure de production, pas une expérience.

Pourquoi Hermes est déjà dans le nouveau train

« Déjà à bord » n’est pas du marketing — vérifiable dans le code. Hermes embarque mcp 2.0.0, dont les notes de release indiquent qu’il implémente la révision 2026-07-28. La nouvelle spécification n’est pas quelque chose que Hermes poursuit ; c’est ce contre quoi tournent déjà ses exécutions quotidiennes. Caractéristique par caractéristique, dans tools/mcp_tool.py :

  • MRTR : le code gère explicitement resultType: "input_required", reconnaissant les serveurs modernes avec le nouveau modèle
  • server/discover : en mode sans état, Hermes sonde server/discover d’abord, avec une nouvelle tentative legacy pour les serveurs à SDK ancien — les deux générations se connectent
  • Elicitation : un handler elicitation/create route les demandes en mode formulaire par le flux d’approbation existant de Hermes (approbation depuis Feishu/Telegram/Slack)
  • Transports : stdio, HTTP/StreamableHTTP et SSE, tous couverts
  • OAuth : gestion complète de client OAuth, jumelée à la skill remote gateway
  • Sens inverse : hermes mcp serve transforme Hermes en serveur MCP, donc n’importe quel client MCP — Claude Code, Cursor, Codex — peut se connecter aux conversations, envoyer des messages et approuver des requêtes

Ajoutez le rechargement à chaud /reload-mcp, un watchdog stdio et les contrôles de sécurité MCP : l’histoire MCP de Hermes est une implémentation complète de la nouvelle spécification, pas un minimum « on supporte le protocole ».

Configurer MCP dans Hermes

Si vous n’avez pas encore branché de serveur MCP, ajoutez un bloc mcp_servers dans ~/.hermes/config.yaml — stdio et distant fonctionnent tous deux :

mcp_servers:
  filesystem:
    command: npx
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/data"]
  my-remote-server:
    url: "https://mcp.example.com/mcp"
    headers:
      Authorization: "Bearer your-token"
  • command + args : serveur stdio local (lancé en sous-processus, avec watchdog pour le redémarrer)
  • url : serveur distant Streamable HTTP / SSE, en-têtes personnalisés supportés
  • Après édition, exécutez /reload-mcp pour recharger à chaud, ou redémarrez Hermes ; hermes mcp serve expose Hermes dans le sens inverse

Pour la référence complète des champs (choix du transport, OAuth, timeouts), voir la référence de configuration MCP ; pour les pièges du quotidien et les astuces de variables de contexte, notre guide sur la config MCP et les variables de contexte est un bon point de départ.

Ce que les prochaines étapes de la feuille de route signifient pour les utilisateurs de Hermes

Plusieurs directions de la feuille de route se projettent directement sur l’usage de Hermes :

  • Tasks entrant dans la spécification + webhooks : les tâches MCP deviennent une primitive standard. La machinerie cron et tâches de fond de Hermes est mûre — une voie bidirectionnelle naturelle quand les Tasks MCP atterriront, laissant d’autres agents invoquer vos jobs planifiés.
  • DPoP et identité d’agent : les agents cloud obtiennent l’autorisation MCP sans humain dans la boucle. Un Hermes 24h/24 sur un VPS est exactement cette forme — quand l’identité « agent agissant pour un utilisateur » mûrira, les agents durables comme Hermes seront les premiers bénéficiaires.
  • Découverte progressive des outils : fini de payer pour un catalogue géant d’avance. Hermes fait déjà de l’élagage de toolsets et de l’optimisation de schémas ; cette direction rend meilleurs les serveurs à grandes surfaces d’outils.

Résumé

La nouvelle feuille de route MCP en dit long, mais se réduit à trois phrases : le protocole est désormais sans état et natif HTTP ; le prochain semestre se concentre sur les primitives de messagerie agente, l’identité d’agent et l’expérience développeur ; les SEP sont priorisés contre ces cinq axes. Pour les utilisateurs de Hermes, la partie rassurante est que la nouvelle spécification n’est pas au « futur » — votre Hermes tourne déjà avec au quotidien. Pour les détails au niveau protocole, lisez le billet officiel de la feuille de route et l’annonce de la spécification 2026-07-28 ; pour voir ce que Hermes peut faire d’autre avec MCP, cette démonstration SEO-MCP est un bon point de départ.