MCP veröffentlicht neue Roadmap mit Fokus auf HTTP und Identität

Die Core Maintainer des Model Context Protocol (MCP), des offenen Standards unter dem Dach der Agentic AI Foundation (AAIF) der Linux Foundation, haben eine aktualisierte Roadmap veröffentlicht, die die Richtung für die nächste Spezifikationsversion und darüber hinaus vorgibt. Wie das japanische Fachmedium Publickey berichtete, gliedert sich die Roadmap in fünf Prioritätsbereiche: Messaging für Agenten, Vereinheitlichung des Transports auf HTTP, Agenten-Identität und unternehmenstaugliche Sicherheit, verbesserte Basiswerkzeuge sowie eine bessere Entwicklererfahrung bei den SDKs. Der offizielle MCP-Blog bestätigt, dass die Roadmap gemeinsam von den Core Maintainern und der Community der Working Groups erarbeitet wurde und "die Richtung der Protokollarbeit für die kommenden Monate" vorgibt.

MCP entstand im November 2024 als Protokoll, das Anthropic vorschlug, um seine Claude-Modelle mit externen Datenquellen und Werkzeugen zu verbinden. Am 9. Dezember 2025 gab die Linux Foundation bekannt, das Protokoll als Spende erhalten und die Agentic AI Foundation zur Steuerung seiner Weiterentwicklung gegründet zu haben, mit Amazon Web Services, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft und OpenAI als Platin-Mitgliedern. Laut der Ankündigung der Linux Foundation wurde MCP zu einem der am schnellsten wachsenden Open-Source-Projekte des vergangenen Jahres, mit über 97 Millionen monatlichen SDK-Downloads und mehr als 10.000 aktiven Servern, fest integriert in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot und Visual Studio Code. Im Juli erreichte die Erweiterung "Enterprise-Managed Authorization" (EMA) den stabilen Status, und das Protokoll wechselte zu zustandslosen Verbindungen — ein großes Update, das groß angelegte Deployments deutlich erleichtert.

Fünf Prioritätsbereiche

Laut dem offiziellen Beitrag "The New MCP Roadmap" knüpft dieses Update an die im März veröffentlichte vorherige Roadmap an, die vier Prioritäten hatte: Weiterentwicklung und Skalierbarkeit des Transports, Kommunikation zwischen Agenten, Reifung der Governance und Unternehmenstauglichkeit. Der Großteil der Fortschritte der vergangenen fünf Monate ist in die Spezifikationsversion vom 28. Juli 2026 (2026-07-28) eingeflossen. Protokollebene-Sitzungen und der Initialisierungs-Handshake wurden entfernt, sodass Server horizontal skalieren können, ohne Zustand zu halten (SEP-2575, SEP-2567); Clients erhielten einen `server/discover`-Aufruf, um die Fähigkeiten eines Servers vor der Verbindung abzufragen; und Listenergebnisse wurden cachefähig (SEP-2549).

• Messaging für Agenten: server-initiierte Ereignisse (Webhooks und Kanäle) ausbauen, damit Clients nicht mehr auf Ergebnisse pollen müssen, und die Tasks-Erweiterung (SEP-2663) bis zur Aufnahme in die Kernspezifikation reifen lassen
• Vereinheitlichung des Transports auf HTTP: Streamable HTTP auch auf lokale Server ausweiten, mittels HTTP/2 über stdio, um Multiplexing-Vorteile bei gleichzeitigen Sicherheits- und Lebenszyklusgarantien eines Subprozesses zu erhalten
• Agenten-Identität und unternehmenstaugliche Sicherheit: Demonstrating Proof of Possession (DPoP) finalisieren und Agenten-Identität sowie Delegation über Workload Identity Federation (SEP-1933) und ID-JAG-Token-Austausch definieren, statt eingefügter API-Schlüssel oder langlebiger Tokens
• Verbesserte Basiswerkzeuge: die Struktur von `tools/call`-Antworten standardisieren und schrittweise Entdeckung (progressive discovery) einführen, damit ein Modell nicht den gesamten Werkzeugkatalog eines Servers laden muss, bevor überhaupt eine erste Nutzerfrage gestellt wurde
• Bessere Entwicklererfahrung bei den SDKs: API-Ergonomie und Dokumentationsgenauigkeit schärfen, da immer mehr Entwickler — und zunehmend auch KI-Agenten selbst — MCP-Client- oder Servercode direkt anhand der SDKs schreiben

Was das für Unternehmen löst

Das aktuelle MCP-Autorisierungsmodell setzt voraus, dass ein Mensch den Zugriff im Browser freigibt. Der offizielle Blog weist darauf hin, dass ein wachsender Anteil der Aufrufer inzwischen Agenten sind, die als Cloud-Workloads mit eigener Identität laufen, im Namen eines abwesenden Nutzers handeln oder eingeschränkte Befugnisse an Sub-Agenten delegieren. Die Identitätsarbeit im Rahmen der Roadmap zielt darauf ab, MCP-Servern einen standardisierten Weg zu geben, diese Agenten-Identitäten zu erkennen und ihnen zu vertrauen — gestützt auf bestehende Standards statt auf eingefügte API-Schlüssel, in Abstimmung mit den Arbeitsgruppen IETF OAuth und WIMSE bei der zugrunde liegenden Token-Austausch-Mechanik. Die Vereinheitlichung auf HTTP zählt operativ genauso stark: Ein remote MCP-Server auf Basis von Streamable HTTP unterscheidet sich inzwischen nicht mehr von jedem anderen HTTP-Workload, sodass Unternehmen ihn auf derselben Infrastruktur — Load Balancer, Gateways, Observability — hosten und skalieren können, die sie bereits für ihre APIs nutzen, statt eine maßgeschneiderte Infrastruktur für ein separates Protokoll aufzubauen.

Bei der Priorisierung äußert sich der offizielle Blog eindeutig: Vorschläge (SEPs), die einem der fünf Prioritätsbereiche zugeordnet sind, erhalten eine beschleunigte Prüfung, während andere nicht automatisch abgelehnt werden, aber mit längeren Fristen und einer höheren Begründungshürde rechnen müssen — die Prüfkapazität der Maintainer ist begrenzt und wird bewusst auf diese fünf Bereiche konzentriert.

Warum das für Teams zählt, die Agenten bauen

MCP ist bereits der Konnektor, über den die meisten großen KI-Produkte — ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, Visual Studio Code — externe Werkzeuge erreichen, was diese Roadmap zu weit mehr als einem internen Engineering-Dokument macht: Sie zeigt, wohin sich der De-facto-Standard für die Anbindung von Agenten an Werkzeuge als Nächstes entwickelt. Für Unternehmen, die KI-Agenten mit internen Systemen verdrahten, dürfte die HTTP-Vereinheitlichung die Betriebskosten für großskalige MCP-Server senken, da eine separate Infrastruktur für stdio- oder WebSocket-basierte Deployments entfällt. Die Identitätsarbeit adressiert ein sehr konkretes Risiko, das Teams bereits tragen: API-Schlüssel, die zwischen Diensten geteilt werden oder gültig bleiben, nachdem ein Mitarbeiter die Rolle gewechselt hat. Ein standardisierter Weg, agenteneigene Zugangsdaten einzugrenzen und zu widerrufen, gestützt auf Audit-Trails, ersetzt informelles Schlüssel-Teilen durch etwas, das ein Sicherheitsteam tatsächlich steuern kann. Organisationen, die ihre MCP-Verbindungen heute mit langlebigen Tokens authentifizieren, sollten dies als frühes Signal werten, eine Migration zu planen, sobald diese Identitäts- und Delegationsarbeit ausgeliefert wird.