16 Monate nach dem Open-Source-Release hat MCP eine offizielle Roadmap bekommen. Nicht die übliche “Q2: Feature X, Q3: Feature Y”-Aufzählung, sondern vier Prioritätsbereiche mit Working Groups, die eigene Timelines setzen. Das ist ein Signal: MCP verhält sich jetzt wie ein Industriestandard, nicht wie ein Startup-Projekt.
Wer unsere Posts zum MCP Maturity Model und Skills vs. MCP gelesen hat, erkennt die gleichen Themen wieder — die Roadmap benennt offiziell, was wir dort schon beschrieben haben. Konkret: was sich ändert und wo die Lücken bleiben.
Was in der Roadmap steht
David Soria Parra, Lead Maintainer, hat die Roadmap am 9. März veröffentlicht. Vier Prioritäten, jeweils einer Working Group zugeordnet.
1. Transport: Stateless und discoverable
Streamable HTTP hat Remote-MCP-Server ermöglicht, aber in der Produktion zeigen sich die Grenzen: Stateful Sessions vertragen sich nicht mit Load Balancern, horizontales Skalieren erfordert Workarounds, und es gibt keine Möglichkeit, die Fähigkeiten eines Servers zu entdecken, ohne sich zu verbinden.
Die geplante Lösung hat zwei Teile. Erstens: Streamable HTTP soll stateless werden, mit definierten Mechanismen für Session-Erstellung, -Wiederaufnahme und -Migration. Zweitens: MCP Server Cards (SEP-1649), ein .well-known-URL-Standard, über den Server strukturierte Metadaten exponieren. Ein simpler HTTP GET auf /.well-known/mcp/server-card.json reicht, um die Capabilities zu lesen — ohne den vollen MCP-Handshake (Initialize, Capability Negotiation, Session State).
Server Cards sind interessant, weil sie das Token-Bloat-Problem an der Wurzel angreifen könnten. Wenn ein Client vor der Verbindung weiß, welche Tools ein Server hat, kann er filtern statt alles laden. Dasselbe Progressive-Disclosure-Muster wie in Skills vs. MCP — nur eine Ebene tiefer im Stack.
Ziel: SEPs in Q1 2026 finalisieren, ein mögliches Spec-Release im Juni 2026.
2. Agent Communication: Tasks reifen nach
Das Tasks-Primitive (SEP-1686) wurde als experimentelles Feature released. Es ermöglicht ein Call-now-fetch-later-Pattern für langlebige Operationen. Im Produktionseinsatz zeigen sich jetzt Lücken: Was passiert bei transienten Fehlern? Wer entscheidet über Retries? Wie lange bleiben Ergebnisse nach Abschluss verfügbar?
Das klingt nach Details, aber für agentic Workflows sind es genau die Fragen, die den Unterschied zwischen Demo und Produktion machen. Die Agents Working Group soll das iterativ verbessern: experimentell releasen, Produktions-Feedback sammeln, nachschärfen.
3. Governance: Weniger Bottleneck, mehr Delegation
Aktuell muss jeder SEP (Spec Enhancement Proposal) durch ein vollständiges Core-Maintainer-Review, egal wie spezialisiert das Thema ist. Das skaliert nicht.
Die Governance Working Group soll eine Contributor Ladder definieren (Community-Teilnehmer bis Core Maintainer mit klaren Aufstiegskriterien) und ein Delegationsmodell, bei dem vertrauenswürdige Working Groups SEPs in ihrem Fachgebiet eigenständig annehmen können. Dazu kommt ein Charter-Template für jede Working Group mit Scope, Deliverables und Retirement-Bedingungen, quartalsweise überprüft.
Das ist die weniger glamouröse, aber wahrscheinlich wichtigste Veränderung. Ein Protokoll, das von einer Handvoll Maintainer abhängt, hat ein Bus-Factor-Problem. Die Formalisierung von SEP-1302 (Working Groups) und SEP-2085 (Succession und Amendments) zeigt, dass das ernst gemeint ist.
4. Enterprise Readiness: Bewusst offen gelassen
Die vierte Priorität ist absichtlich vage gehalten. Audit Trails, SSO-Integration (weg von statischen Client Secrets, hin zu Cross-App-Access-Patterns), Gateway-Verhalten (Authorization Propagation, Session Semantics), Konfigurations-Portabilität.
Auffällig: Eine Enterprise Working Group existiert noch nicht. Die Roadmap sagt explizit, dass Praktiker die Arbeit treiben sollen. Und das meiste soll als Extensions landen, nicht als Core-Spec-Änderung.
Das ist eine bewusste Designentscheidung. Die Core Spec soll schlank bleiben, Enterprise-Features kommen als opt-in Erweiterungen. Ob das in der Praxis funktioniert, wird sich zeigen. Das Extensions-System ist noch jung (MCP Apps als erste GA-Extension seit Januar 2026), aber der Dreischicht-Ansatz (Core Spec, Supporting Projects, Extensions) ist sauber.
Darüber hinaus
Jenseits der vier Prioritäten listet die Roadmap niedrig-priorisierte Themen, die von der Community getrieben werden sollen:
- Triggers und Event-driven Updates: Webhooks statt Polling/SSE
- Result-Type-Verbesserungen: Streaming für inkrementelle Ergebnisse, Referenz-basierte Results für große Payloads
- Security: DPoP (SEP-1932), Workload Identity Federation (SEP-1933), Least-Privilege Scopes, ein Vulnerability-Disclosure-Programm über die Linux Foundation
- Extensions-Ökosystem: Die Skills-Primitive für kompositionelle Capabilities, First-Class-Extension-Support in der Registry
Parallel dazu entsteht eine Validierungsinfrastruktur: Conformance Test Suites, SDK-Tiers (SEP-1730) zur Kennzeichnung, welche SDKs die Spec am engsten verfolgen, und Referenz-Implementierungen.
Was die Roadmap über den Zustand von MCP verrät
Die Roadmap ist ungewöhnlich ehrlich über die Produktionslücken. Streamable HTTP hat “production pain points”. Tasks hat “gaps revealed by production usage”. Auth ist immer noch das härteste ungelöste Problem. Das sind keine Schwächen der Roadmap. Es ist die Stärke: sie beschreibt den tatsächlichen Zustand, nicht eine Marketing-Vision.
Aber es gibt berechtigte Kritik. Perplexitys CTO Denis Yarats hat Anfang März öffentlich gesagt, dass Perplexity intern von MCP weggeht. Sein Argument: Tool-Beschreibungen verbrauchen 40-50% des Context Windows, bevor Agents Arbeit leisten. Ein Team berichtete von 143.000 von 200.000 Tokens (72%) allein für Tool-Definitionen. Benchmarks zeigen den 4-32-fachen Token-Verbrauch im Vergleich zu CLI-Äquivalenten.
Das widerspricht der Roadmap nicht. Server Cards und die Transport-Evolution sollen genau dieses Problem lösen — Stand heute existiert die Lösung in der Spec aber noch nicht. Wer jetzt mit MCP in Produktion geht, braucht eigene Mitigationen: Tool-Filtering über ein Gateway, Progressive Disclosure über eine Orchestrierungsschicht, oder beides.
Was das für uns bedeutet
Die Roadmap bestätigt den Weg, den wir im MCP Maturity Model beschrieben haben. Die Probleme auf Stufe 1 (Token-Explosion, schlechte Beschreibungen, fehlende Auth) sind jetzt offizielle Prioritäten.
Drei Dinge, die ich konkret mitnehme:
Server Cards beobachten. Wenn SEP-1649 in der Juni-Spec landet, ändert sich die Discovery-Story grundlegend. Statt alle Tools blind zu laden, kann ein Client vorher filtern. Das ist der größte Einzelhebel gegen Token-Bloat auf Protokollebene.
Bei Enterprise-Themen bleibt das Protokoll bewusst dünn: Auth, Audit Trails und Gateway-Verhalten kommen über Extensions, die noch reifen müssen. Viele Teams fangen das schon heute mit einer Gateway-Schicht (Policy, Auth-Weitergabe, Tool-Filter) ab, statt auf die Spec zu warten — die Roadmap sagt implizit, dass Enterprise-Readiness eine Infrastrukturschicht darüber braucht, nicht nur eine dickere Core-Spec.
Aufschlussreich wird auch der MCP Dev Summit am 2.-3. April in New York: 95+ Sessions, darunter Conformance Testing (Anthropic), Mix-Up Attacks (Microsoft) und “When MCP Isn’t Enough” (Datadog). Die Diskussionen dort zeigen, ob die Working-Group-Struktur greift oder ein Governance-Experiment bleibt.
MCP hat sich als Standard durchgesetzt. Die Roadmap zeigt, dass die Maintainer das ernst nehmen. Aber zwischen “De-facto-Standard” und “produktionsreif für Enterprise” liegt noch Arbeit. Das Maturity Model gilt weiterhin: Wer auf Stufe 1 stehen bleibt, wird die Probleme erleben. Wer Richtung Stufe 3 und 4 baut, hat jetzt einen klareren Blick darauf, wohin das Protokoll selbst sich bewegt.