MCP kündigt neue Roadmap an — und Hermes ist schon auf dem neuen Standard

Letzten Monat hast du einen Nachmittag damit verbracht, ein paar interne Tools an MCP (Model Context Protocol, den De-facto-Standard, um KI-Anwendungen mit externen Systemen und Daten zu verbinden) anzubinden. Server einzeln konfiguriert, Berechtigungen gesetzt, alles lief. Und diese Woche siehst du die News: MCP kündigt eine neue Roadmap an — „Protokoll-Sitzungen entfernt“, „server-initiated Requests ersetzt“. Dein erster Gedanke ist wahrscheinlich: schon wieder eine Migration? Atme durch. Dieser Beitrag zerlegt, was die am 22. August veröffentlichte offizielle Roadmap wirklich sagt, welche Änderungen bereits in der Spezifikation 2026-07-28 gelandet sind und warum Hermes-Nutzer schon auf dem neuen Zug sitzen.

Was MCP angekündigt hat: eine Roadmap mit fünf Prioritäten

Am 22. August haben die beiden Lead-Maintainer von MCP — David Soria Parra und Den Delimarsky — den offiziellen Blogpost The New MCP Roadmap veröffentlicht, mit passendem Update auf der Roadmap-Seite. Es ist die formale Fortschreibung der März-Roadmap (Transportentwicklung, Agent-Kommunikation, Governance-Reifung, Enterprise-Bereitschaft): Der Großteil der Arbeit der letzten fünf Monate ist bereits in die Spezifikation 2026-07-28 eingeflossen, und die neue Roadmap bündelt das Kommende in fünf Schwerpunktbereiche:

  1. Agentic Messaging Primitives: Moderne Agent-Workloads passen nicht mehr ins Request-Response-Muster. Die Roadmap will Tasks (asynchrone Langläufer) in den Spezifikationstext holen, plus Server-initiated Events (Webhooks und Kanäle, damit Clients nicht auf Ergebnisse pollen müssen), subscriptions/listen und Fortschrittsbenachrichtigungen.
  2. HTTP-native Transportvereinheitlichung und -härtung: Seit 2026-07-28 ist ein entfernter MCP-Server „wie jede andere HTTP-Workload“ — deine Load Balancer, Scale-to-Zero-Serverless und Readiness-Probes greifen alle. Nächster Schritt: lokale Server auf Streamable HTTP über stdio vereinheitlichen.
  3. Agent-Identität und Enterprise-Sicherheit: MCP-Autorisierung setzt heute voraus, dass eine Person im Browser genehmigt — aber immer mehr Aufrufer sind Cloud-Workloads ohne menschliche Anwesenheit. Die Roadmap zielt auf DPoP (RFC 9449 Proof of Possession), Workload Identity Federation, standardisierten Token-Austausch, mit laufender Beteiligung an den IETF-OAuth- und WIMSE-Arbeitsgruppen.
  4. Verbesserte Primitive: tools/call-Antworten sollen einen klaren Vertrag haben statt mehrerer Formen; und damit das Modell nicht für einen Katalog mit hundert Tools bezahlt, bevor der Nutzer eine einzige Frage stellt, startet ein Progressive-Discovery-Vorhaben: Der Server bietet einen kleinen Einstiegspunkt und gibt mehr frei, sobald sich das Gespräch verengt.
  5. Bessere SDK-Entwicklererfahrung: Ergonomie und Konformität über alle offiziellen SDKs.

Ein praktischer Nebeneffekt: SEPs in diesen Schwerpunktbereichen werden beschleunigt reviewed. Wenn du einen Vorschlag planst, ist das die Karte, an der du dich ausrichtest.

Was bereits in der Spezifikation 2026-07-28 gelandet ist: vier große Änderungen

Die Roadmap sagt: „Der Großteil der Änderungen kam mit dem 2026-07-28-Release.“ Was genau, für einen arbeitenden Entwickler?

1. Das Protokoll wurde staatenlos. Mit SEP-2575 (Stateless MCP) und SEP-2567 (Sessionless MCP) sind die Protokoll-Sitzung und der Initialisierungs-Handshake weg. Ein entfernter MCP-Server ist jetzt einfach ein HTTP-Dienst: Lastverteilung ohne Sticky Sessions, Scale-to-Zero wenn du willst. Wenn dein Server Zustand zwischen Aufrufen braucht, präge ein explizites Handle aus einem Tool und lass das Modell es als Argument zurückgeben — transparenter als versteckte Transport-Sessions.

2. MRTR ersetzt Server-initiated Requests. In der alten Spezifikation konnten Server in den Client zurückrufen (z. B. um einen Parameter zu bestätigen) — unangenehm bei staatenlosen Deployments und hinter Unternehmens-Firewalls. Das Multi-Round-Trip-Muster (SEP-2322) funktioniert so: Der Server liefert resultType: "input_required" samt der Requests, die er beantwortet braucht, und der Client wiederholt den ursprünglichen Aufruf mit den Antworten in inputResponses. Elicitation, Sampling und Roots sind auf dieses Modell umgezogen.

3. Discovery und Caching. Ein Client kann server/discover aufrufen, um unterstützte Versionen und Fähigkeiten vor dem Verbinden zu erfahren; List-Ergebnisse tragen Cache-Hinweise und deterministische Ordnung (SEP-2549), sodass Clients Tool-Kataloge cachen und vorgelagerte Prompt-Caches über Reconnects stabil bleiben.

4. Header-basiertes Routing und Autorisierungs-Härtung. Methoden- und Tool-Namen reisen in den HTTP-Headern Mcp-Method und Mcp-Name, Gateways können also allein anhand der Header routen und autorisieren; die Autorisierung bekam Issuer-Validierung, Issuer-gebundene Client-Credentials und Client ID Metadata Documents (CIMD), mit Enterprise-Managed Authorization als stabiler Extension. AWS hat Tasks bereits in Bedrock AgentCore gelandet, und das Agents SDK von Cloudflare unterstützt die Spezifikation ab Tag eins — das ist Produktionsinfrastruktur, kein Experiment.

Warum Hermes schon auf dem neuen Zug sitzt

„Schon an Bord“ ist kein Marketing-Sprech — man kann es im Code nachprüfen. Hermes bringt mcp 2.0.0 mit, dessen Release-Notes explizit sagen, dass es die Revision 2026-07-28 implementiert. Die neue Spezifikation ist nichts, was Hermes jagt; es ist das, wogegen die täglichen Läufe bereits arbeiten. Feature für Feature, in tools/mcp_tool.py:

  • MRTR: Der Code behandelt explizit resultType: "input_required" und erkennt moderne Server mit dem neuen Muster
  • server/discover: Im stateless-Modus probt Hermes zuerst server/discover, mit Legacy-Retry für ältere SDK-Server — beide Generationen verbinden sich
  • Elicitation: Ein elicitation/create-Handler leitet Formular-Anfragen durch Hermes’ bestehenden Genehmigungsfluss (Genehmigung direkt aus Feishu/Telegram/Slack)
  • Transports: stdio, HTTP/StreamableHTTP und SSE, alle abgedeckt
  • OAuth: Vollständiges OAuth-Client-Management, gepaart mit der Remote-Gateway-Skill
  • Umgekehrte Richtung: hermes mcp serve macht Hermes selbst zum MCP-Server, sodass jeder MCP-Client — Claude Code, Cursor, Codex — sich mit Konversationen verbinden, Nachrichten senden und Anfragen genehmigen kann

Dazu Hot-Reload über /reload-mcp, ein stdio-Watchdog und MCP-Sicherheitschecks: Hermes’ MCP-Geschichte ist eine vollständige Implementierung der neuen Spezifikation, kein „wir unterstützen das Protokoll“-Minimum.

MCP in Hermes konfigurieren

Wenn du noch keinen MCP-Server angebunden hast, ergänze einen mcp_servers-Block in ~/.hermes/config.yaml — stdio und Remote funktionieren beide:

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: lokaler stdio-Server (als Subprozess gestartet, mit Watchdog für Neustarts)
  • url: entfernter Streamable-HTTP-/SSE-Server, benutzerdefinierte Header möglich
  • Nach dem Editieren /reload-mcp für Hot-Reload ausführen oder Hermes neu starten; hermes mcp serve exponiert Hermes in umgekehrter Richtung

Für die vollständige Feldreferenz (Transportwahl, OAuth, Timeouts) siehe die offizielle MCP-Konfigurationsreferenz; für Alltags-Tipps und Context-Variable-Tricks ist unser Guide zu MCP-Config und Context-Variablen ein guter Einstieg.

Was die nächsten Roadmap-Schritte für Hermes-Nutzer bedeuten

Mehrere Roadmap-Richtungen mappen direkt auf die Hermes-Nutzung:

  • Tasks ziehen in die Spezifikation + Webhooks: MCP-Tasks werden ein Standard-Primitiv. Hermes’ Cron- und Hintergrund-Task-Maschinerie ist ausgereift — ein natürlicher bidirektionaler Kanal, wenn MCP-Tasks kommen, sodass andere Agenten deine geplanten Jobs aufrufen können.
  • DPoP und Agent-Identität: Cloud-Agenten bekommen MCP-Autorisierung ohne Menschen im Loop. Ein 24/7-Hermes auf einem VPS ist genau diese Form — wenn die Identität „Agent im Auftrag eines Nutzers“ reift, sind langlebige Agenten wie Hermes die ersten Nutznießer.
  • Progressives Tool-Discovery: Schluss mit dem Vorab-Bezahlen für riesige Kataloge. Hermes macht bereits Toolset-Trimming und Schema-Optimierung; diese Richtung macht Server mit großen Tool-Oberflächen für alle besser.

Zusammenfassung

Die neue MCP-Roadmap packt viel, aber sie reduziert sich auf drei Sätze: Das Protokoll ist jetzt staatenlos und HTTP-nativ; das nächste halbe Jahr fokussiert Agentic Messaging Primitives, Agent-Identität und Entwicklererfahrung; SEPs werden gegen diese fünf Bereiche priorisiert. Für Hermes-Nutzer ist der beruhigende Teil, dass die neue Spezifikation keine „Zukunftsform“ ist — dein Hermes läuft täglich schon damit. Für die Protokoll-Details lies den offiziellen Roadmap-Post und die Ankündigung der 2026-07-28-Spezifikation; um zu sehen, was Hermes mit MCP sonst noch kann, ist dieser SEO-MCP-Durchlauf ein solider Startpunkt.