MCPs neue Roadmap: Was sie für Menschen bedeutet, die darauf bauen

Am 22. August veröffentlichten die Maintainer des Model Context Protocol eine aktualisierte Roadmap, die die nächsten sechs bis zwölf Monate der Protokollarbeit abdeckt. Sie nennt fünf Prioritätsbereiche, die jeweils verantwortlichen Core Maintainers und eine stille, aber wichtige Regel dafür, welche Proposals zuerst reviewed werden. Die vorherige Roadmap vom März versprach vier Dinge und lieferte den Großteil davon im Spezifikationsrelease vom Juli aus. Deshalb hat sich diese Version das Recht verdient, ernst genommen zu werden. Meine Lesart: MCP wird absichtlich zu gewöhnlicher Web-Infrastruktur, und die nützliche Frage für Builder lautet, welchen Teil Ihres Stacks das zuerst verändert.

Wichtigste Erkenntnisse - Die Roadmap setzt fünf Prioritäten: agentic messaging, ein einziger HTTP-nativer Transport, Agent Identity und Enterprise Security, sauberere Tool-Primitives und aus der Spezifikation generierte SDKs. - Spec Enhancement Proposals, SEPs, innerhalb dieser Bereiche erhalten beschleunigtes Review. Außerhalb davon ist mit einer längeren Queue und einer höheren Hürde zu rechnen. - Die Zusagen der Roadmap vom März landeten weitgehend in der Spezifikation 2026-07-28: stateless core, cachebare List Results und Multi Round-Trip Requests. - Die zwei Änderungen, die Ihren Code am wahrscheinlichsten betreffen, sind Agent Identity, DPoP und Workload Identity Federation, sowie Progressive Tool Discovery für große Kataloge. - Behandeln Sie die Roadmap als Richtung, nicht als Zusage. Die Maintainer sagen das selbst. Pausieren Sie keinen Build dafür.

Was haben die MCP-Maintainer tatsächlich angekündigt?

Zuerst die Fakten. Die aktualisierte MCP-Roadmap, datiert auf den 22. August 2026, organisiert den nächsten Spec-Zyklus um fünf Prioritätsbereiche, jeweils mit benannten Core Maintainers und einer oder mehreren Working Groups dahinter:

1. Agentic messaging primitives: server-initiierte Events, Channels, Subscriptions und Webhooks, damit Clients nicht mehr pollen müssen, plus ein Composition Review, damit Tasks, Triggers und Progress Notifications einen gemeinsamen Lifecycle erhalten.

2. HTTP-native transport unification and hardening: Streamable HTTP als einziges Binding, später auch über stdio für lokale Server, und erweitertes Caching mit ETags.

3. Agent identity and enterprise-ready security: Finalisierung von DPoP, Demonstrating Proof of Possession, sowie ein opinionated Pfad für Agent Identity und Delegation auf Basis bestehender IETF-Standards.

4. Improved primitives: ein Redesign der tools/call Result Shape und eine neue Progressive-Discovery-Initiative, damit Clients den Katalog eines Servers nur nach Bedarf kennenlernen.

5. Improved SDK developer experience: ein Extension Contract und ein Experiment, ein Tier-1-SDK samt Quickstarts direkt aus der Spezifikation zu generieren.

Neben den fünf Bereichen steht eine Regel, die alles andere prägen wird: SEPs innerhalb dieser Prioritäten erhalten beschleunigtes Review, und Proposals mit einer Working Group im Rücken bewegen sich am schnellsten. Mit den Worten der Maintainer: "maintainer review time is scarce. We spend it here first." Die Roadmap sagt außerdem ausdrücklich, dass sie aktuelle Denkweise und keine festen Commitments widerspiegelt. Einzelne Items können also rutschen oder in anderer Form erscheinen.

Die am 22. August 2026 veröffentlichte MCP-Roadmap setzt fünf Prioritätsbereiche für die nächsten sechs bis zwölf Monate: agentic messaging, HTTP-nativer Transport, Agent Identity, verbesserte Tool-Primitives und spec-generierte SDKs. Proposals innerhalb dieser Bereiche bekommen beschleunigtes Review; außerhalb wartet eine längere Queue.

Warum ist diese Roadmap wichtig?

Sie ist wichtig, weil die letzte geliefert hat. Roadmaps junger Open-Source-Projekte sind oft aspirative Dokumente, die still veralten. Diese hat einen Track Record. Die Roadmap vom März 2026 setzte vier Prioritäten, und der Großteil landete fünf Monate später im Spezifikationsrelease 2026-07-28:

Adoption gibt der Roadmap Gewicht. Bis Juli 2026 verzeichneten die Tier-1-SDKs des Protokolls nahezu eine halbe Milliarde Downloads pro Monat, wobei TypeScript- und Python-SDK jeweils mehr als eine Milliarde Downloads insgesamt überschritten hatten. Wenn ein Protokoll in dieser Größenordnung sagt, wohin es geht, lohnt es sich, die Karte zu lesen.

Quelle: MCP-Roadmap vom März und August 2026 sowie die Ankündigung der Spezifikation 2026-07-28.

Die MCP-Roadmap vom März 2026 versprach Transport Evolution, Agent Communication, Governance Maturation und Enterprise Readiness. Fünf Monate später lieferte die Spezifikation 2026-07-28 einen stateless Protocol Core, die Tasks Extension, Multi Round-Trip Requests und eine formale Deprecation Policy mit mindestens zwölf Monaten aus.

Was bedeutet das, wenn Sie auf MCP bauen?

Für Builder ist die unmittelbare Wirkung ungleich verteilt. Zwei der fünf Bereiche werden Ihren Code wahrscheinlich innerhalb eines Jahres verändern. Die anderen drei verändern vor allem, wie das Protokoll um Sie herum governed und maintained wird. Hier ist jeder Bereich übersetzt.

Agentic messaging: das Ende des Pollings

Echte Agent-Arbeit passt nicht in Request und Response. Jobs laufen minutenlang, Server werden fertig, während der Client nicht hinsieht, und heute bleibt dem Client meist nur Polling, was teuer und hässlich ist. Die Roadmap priorisiert server-initiated Events: Channels, Subscriptions und Webhooks, damit ein Server Ihrem Client sagen kann, wenn die Arbeit fertig ist. Das Composition Review ist ebenso wichtig. Tasks, subscriptions/listen und Progress Notifications riskieren derzeit, drei verschiedene Antworten auf "der Server ist noch nicht fertig" zu werden. Die Maintainer wollen einen gemeinsamen Lifecycle, ein Cancellation Model und eine Error Surface. Wenn Sie long-running Tools bauen, ist das der Bereich, den Sie auf Discord beobachten sollten.

Ein Transport, überall gesprochen

Das Release 2026-07-28 machte einen Remote-MCP-Server zu einem gewöhnlichen HTTP-Workload. Die Roadmap will nun die Trennung zwischen remote und local entfernen: Streamable HTTP als einziges Binding, gesprochen über stdin und stdout für lokale Server, mit HTTP/2 für Multiplexing, während der Subprocess seine Security- und Lifecycle-Garantien behält. Heute benötigt jedes HTTP-native Feature ein zweites stdio-spezifisches Design, oder es funktioniert lokal nicht, und SDKs pflegen zwei Transport Pipelines. Ein Transport Model bedeutet weniger davon. Auch Caching wächst: ETags zusätzlich zu den ttlMs- und cacheScope-Hints aus dem Juli, damit Tool Call Results versioniert statt erneut abgerufen werden können.

Agent Identity: die Änderung, die am frühesten beißt

MCP Authorization nimmt einen Menschen mit Browser zur Consent-Zeit an. Zunehmend ist der Caller jedoch ein Agent: ein Cloud Workload mit eigener Identity, der für einen User handelt, der nicht anwesend ist, oder Sub-Agents startet, die weniger Authority als ihr Parent erhalten sollen. Honeycomb, zitiert in der Juli-Release-Ankündigung, führt bereits fast 20% seiner monatlichen interaktiven Queries auf Agents zurück. Gleichzeitig verlassen sich viele Production-MCP-Server noch auf eingefügte API Keys und langlebige Refresh Tokens, genau die Praxis, die diese Arbeit ablösen soll. Der Plan: DPoP finalisieren und übernehmen, plus ein Standard-Delegation-Pfad über Workload Identity Federation, SEP-1933, den ID-JAG Grant hinter Enterprise-Managed Authorization und RFC 8693 Token Exchange, koordiniert mit den IETF OAuth- und WIMSE-Working-Groups.

MCPs Authorization Model wurde für einen Menschen gebaut, der Access im Browser genehmigt, aber Agents werden zunehmend die Caller. Die Roadmap priorisiert DPoP und einen Standard-Delegation-Pfad auf Basis von Workload Identity Federation und RFC 8693 Token Exchange, damit Server Agent Identities ohne eingefügte API Keys oder langlebige Tokens erkennen können.

Tool Results und Progressive Discovery

Hier werden zwei Verwirrungen behoben. Erstens gibt tools/call gleichzeitig content und structuredContent zurück. Das hat divergierende Implementierungen erzeugt, weil ein Server Author nicht wissen kann, welche Form der Client dem Model zeigt. Dieser Contract wird redesigned. Zweitens geht es um Skalierung: Verbinden Sie sich mit einem Server mit hundert Tools, zahlt das Model für die gesamte Surface, bevor der User eine einzige Frage gestellt hat, und Tool Selection wird schlechter, je länger die Liste wird. Der Token-Bill-Effekt ist nicht theoretisch. In Cloudflares Test vom Februar 2026 verbrauchte die Darstellung einer API mit 2.500 Endpoints als MCP Tool Definitions ungefähr 1,17 Millionen Tokens, gegenüber rund 1.000 über Code Calling. Progressive Discovery ist die vorgeschlagene Antwort: ein kleiner Entry Point, der mehr vom Katalog zeigt, während die Conversation enger wird, verbunden mit der Caching-Arbeit oben. Ich habe bereits darüber geschrieben, wann dieser Overhead eine normale API zur besseren Wahl macht; Progressive Discovery ist MCPs Versuch, die Lücke zu verkleinern.

SDKs aus der Spezifikation generiert

Das leiseste Item ist vielleicht das aussagekräftigste. Heute werden SDKs, Reference Servers und Quickstarts von Hand gepflegt. Die Roadmap startet ein Experiment: ein Candidate Tier-1-SDK samt Companion Quickstarts direkt aus der Spezifikation generieren, beides gegen eine Conformance Test Suite validieren und die Ergebnisse veröffentlichen, einschließlich der Frage, welche Layers deterministisches Codegen sein sollten und welche model-assisted. Wenn es funktioniert, werden Spec-Clarity-Bugs durch Generation Failures sichtbar und SDKs driften weniger von dem Dokument weg, das sie implementieren sollen.

Was sollten Sie jetzt tun?

Vier Dinge, nach Dringlichkeit:

1. Diese Woche: Bauen Sie keine neue Arbeit mehr auf deprecated Surfaces. Roots, Sampling, Logging und der Legacy HTTP+SSE Transport wurden in der Spezifikation 2026-07-28 mit mindestens zwölf Monaten Übergangsfrist deprecated. Sie funktionieren weiterhin. Neue Implementierungen sollten sie nicht übernehmen.

2. Diesen Monat: Machen Sie Ihren Server cache-friendly. List Results tragen bereits ttlMs und cacheScope, und ETags kommen. Ein Server, der heute sinnvolle Cache Hints ausgibt, ist eine Migration voraus.

3. Dieses Quartal: Prüfen Sie, wie Ihre Agents authentifizieren. Wenn irgendein MCP-Server, den Sie betreiben, einem eingefügten API Key oder langlebigen Refresh Token für einen unattended Caller vertraut, ist das genau das Muster, das die Agent Identity Working Group ersetzen will. Verfolgen Sie die Gruppe, statt Ihr eigenes Delegation Scheme zu erfinden. Der Governance-Aspekt verbindet sich mit dem, was ich in Governing AI Agents behandelt habe.

4. Wenn Sie das Protokoll mitgestalten wollen: Schreiben Sie Ihr SEP innerhalb eines Prioritätsbereichs. Bringen Sie es zuerst zur relevanten Working Group und holen Sie deren Unterstützung. Proposals, die mit der Roadmap aligned sind, erhalten beschleunigtes Review; Proposals außerhalb warten.

Zwei Dinge nicht tun. Pausieren Sie keinen Build in Erwartung der nächsten Spec: Die aktuelle ist die stabile Basis, und die Deprecation Policy garantiert nun zwölf Monate Warnung, wenn etwas verschwindet, auf das Sie bauen. Und behandeln Sie die Roadmap nicht als Promise. Sie sagt im ersten Abschnitt selbst, dass Prioritäten sich verschieben und nicht gelistete Arbeit trotzdem shippen kann. Wenn Sie früher in der Journey sind, sind mein praktischer Walkthrough für einen ersten MCP Server und die Shortlist lohnenswerter Server die besseren Startpunkte.

Die MCP-Spezifikation 2026-07-28 deprecated Roots, Sampling, Logging und den Legacy HTTP+SSE Transport mit mindestens zwölf Monaten Übergangsfrist. Die Release-Ankündigung bestätigt, dass sie in diesem Zeitraum weiter funktionieren, neue Implementierungen sie aber nicht übernehmen sollten.

Das größere Bild

Treten Sie einen Schritt zurück, und das Muster ist ein Protokoll, das öffentlich erwachsen wird. MCP wurde im Dezember 2025 an die vendor-neutrale Agentic AI Foundation unter der Linux Foundation gespendet, mit OpenAI und Block als Co-Founders. Seitdem erhielt es Contributor Ladder, Feature Lifecycle, Deprecation Policy und nun eine öffentliche Aussage darüber, wohin Maintainer Attention geht. Das Extensions Framework leistet dabei leise, aber echte Arbeit: SEP-2133 erlaubt jeder Working Group, in einem experimental-ext- Repository zu experimentieren, bevor ein formaler Proposal entsteht, sodass Ideen getestet werden können, ohne den Core zu destabilisieren.

Was ich in den nächsten zwei Quartalen beobachten würde, ist HTTP over stdio. Wenn lokale und remote Server wirklich auf einem Transport konvergieren, ist ein "MCP server" keine besondere Softwaregattung mehr, sondern ein Web Service mit standardisiertem Gesicht. An diesem Punkt verschwindet das Protokoll in der Plumbing, und genau das soll gute Infrastruktur tun.

Häufig gestellte Fragen

Ist MCP jetzt stabil genug, um darauf zu bauen?

Ja, mit Migrationsdisziplin. Die Spezifikation 2026-07-28 führte eine formale Deprecation Policy mit mindestens zwölf Monaten ein, und SDKs liefern Migration Notes bei Breaking Changes. Das Protokoll wird sich weiter bewegen, aber es sagt Ihnen jetzt ein Jahr im Voraus, wenn etwas verschwindet, auf das Sie sich verlassen.

Was ist mit MCP Sessions passiert?

Sie wurden in der Spezifikation 2026-07-28 retired. Der initialize-Handshake und der Mcp-Session-Id Header sind weg, SEP-2575 und SEP-2567. Jede Request ist nun self-describing und trägt Protocol Version und Client Capabilities in _meta; ein optionaler server/discover Call ersetzt den Handshake für Clients, die Capabilities upfront wollen. Jede Request kann auf jeder Instance hinter einem Round-Robin Load Balancer landen.

Soll ich auf die nächste Spec warten, bevor ich baue?

Nein. Die Roadmap beschreibt Richtung für die nächsten sechs bis zwölf Monate, keine committed Features, und die Maintainer sagen das ausdrücklich. Die aktuelle Spec ist stabil, cacheable und stateless. Bauen Sie darauf, meiden Sie deprecated Surfaces und verfolgen Sie die zwei Working Groups, deren Output Sie am stärksten betreffen wird.