MCP soll zur Infrastruktur für autonome Agenten werden
Die Core-Maintainer des Model Context Protocol haben die nächsten Entwicklungsschwerpunkte für MCP festgelegt. Der offene Standard soll nicht mehr nur einzelne Werkzeugaufrufe zwischen einem Sprachmodell und externen Systemen vermitteln. Künftig stehen lang laufende Agenten-Prozesse, Unternehmensidentitäten und skalierbare Bereitstellungen im Mittelpunkt.
Die Roadmap definiert fünf Prioritätsbereiche. Dazu gehören neue Kommunikationsmechanismen, ein einheitlicher HTTP-Transport, eine eigene Identität für Agenten, verbesserte Protokollfunktionen sowie leichter nutzbare Software Development Kits, kurz SDKs.
| Prioritätsbereich | Geplante Verbesserung |
|---|---|
| Agentic Messaging Primitives | Webhooks, Kanäle und Steuerung lang laufender Aufgaben |
| HTTP-native Transporte | Einheitliches Transportmodell für entfernte und lokale Server |
| Agenten-Identität | Standardisierte Authentifizierung und delegierbare Rechte |
| Verbesserte Primitives | Einheitliche Tool-Antworten und Progressive Discovery |
| SDK Developer Experience | Klarere Programmierschnittstellen, Dokumentation und Spezifikationstreue |
Zustandslose Server bilden die technische Basis
Ein wesentlicher Umbau ist bereits erfolgt. Protokoll-Sessions und der bisherige Initialisierungs-Handshake wurden abgeschafft. MCP-Server müssen dadurch keinen Sitzungszustand mehr halten und lassen sich horizontal skalieren, also durch zusätzliche Instanzen erweitern.
Clients können über server/discover vor dem ersten Werkzeugaufruf prüfen, welche Protokollversionen und Fähigkeiten ein Server unterstützt. Listenergebnisse dürfen zwischengespeichert werden. Das reduziert wiederholte Abfragen und erleichtert den Betrieb in verteilten Infrastrukturen.
Tasks wurden als offizielle Erweiterung ausgelagert. Gleichzeitig ersetzen Multi Round-Trip Requests die früheren serverinitiierten Anfragen. Damit können mehrstufige Abläufe auch mit zustandslosen Servern umgesetzt werden. Die Grundlagen dieses Umbaus beschreibt auch das vorherige MCP-Update für den Enterprise-Betrieb.
Der Roadmap-Text bezeichnet das zugehörige Spezifikations-Release mit dem Datum 2026-07-28. Ob diese Datierung korrekt ist, bleibt offen. Für die einzelnen neuen Roadmap-Punkte wurden ebenfalls keine verbindlichen Fertigstellungstermine genannt.
Webhooks sollen Polling bei langen Aufgaben ersetzen
Autonome Agenten passen nur bedingt in das klassische Muster aus Anfrage und unmittelbarer Antwort. Aufgaben können länger laufen, Zwischenergebnisse liefern oder während der Bearbeitung neue Vorgaben benötigen. MCP soll dafür serverseitige Ereignisse über Webhooks und Kanäle erhalten.
Clients müssten den Status einer Aufgabe dann nicht mehr fortlaufend abfragen. Das senkt unnötigen Datenverkehr und vereinfacht die Steuerung lang laufender Prozesse. Zugleich sollen Tasks, Fortschrittsmeldungen und Abonnements konsistenter zusammenspielen.
Die Roadmap verschiebt MCP von einer Schnittstelle für einzelne Tool-Aufrufe hin zu einer allgemeinen Kommunikationsschicht für autonome Unternehmensagenten.
HTTP wird zum einheitlichen Transport
Entfernte MCP-Server sollen sich wie gewöhnliche HTTP-Dienste betreiben lassen. Die Roadmap will dieses Modell auch auf lokale Installationen ausweiten. Vorgesehen ist dafür Streamable HTTP over stdio, also HTTP-Kommunikation über die Standardein- und -ausgabe eines lokalen Prozesses.
Ein einheitlicher Transport reduziert Sonderfälle in Clients und Servern. Für Unternehmen ist das vor allem betrieblich relevant: Bestehende API-Infrastruktur, Überwachung und Skalierungsmechanismen lassen sich eher weiterverwenden, statt eine proprietäre Vermittlungsschicht einzuführen.
Agenten erhalten eigene Identitäten und Rechte
Die bisherige MCP-Autorisierung geht häufig davon aus, dass ein Mensch den Zugriff im Browser bestätigt. Dieses Verfahren reicht für Cloud-Workloads und unbeaufsichtigt laufende Agenten nicht aus. Solche Prozesse benötigen eine eigene, überprüfbare Identität und klar begrenzte Berechtigungen.
Geplant sind unter anderem DPoP, Workload Identity Federation, der ID-JAG Grant und standardisierter Token Exchange. DPoP bindet ein Zugriffstoken kryptografisch an den jeweiligen Client und erschwert damit den Missbrauch gestohlener Tokens. Workload Identity Federation ermöglicht es, bestehende Identitäten aus Cloud- und Unternehmenssystemen zu verwenden, ohne dauerhaft gespeicherte API-Schlüssel auszutauschen.
Die Arbeiten werden mit den zuständigen Gruppen für OAuth und Workload-Identitäten abgestimmt. Für Unternehmen im DACH-Raum ist das ein wichtiger Punkt. Bestehende Regeln für Zugriffskontrolle, Protokollierung und Funktionstrennung lassen sich mit standardisierten Identitäten besser auf KI-Agenten übertragen.
Progressive Discovery soll Kontext und Kosten begrenzen
Große MCP-Server können Hunderte Werkzeuge anbieten. Wird der gesamte Katalog bei jeder Anfrage in den Modellkontext geladen, steigen Token-Verbrauch und Kosten. Gleichzeitig wird die Werkzeugauswahl unzuverlässiger, wenn das Modell zwischen zu vielen ähnlichen Funktionen entscheiden muss.
Progressive Discovery soll deshalb zunächst nur einen kleinen Einstiegspunkt offenlegen. Weitere Werkzeuge werden erst sichtbar, wenn sich die Aufgabe konkretisiert. Für umfangreiche interne Fachanwendungen kann das Kontextbedarf, Latenz und Inferenzkosten reduzieren.
Auch die Antworten von tools/call sollen vereinheitlicht werden. Derzeit kann dasselbe Ergebnis in mehreren Formen zurückgegeben werden, ohne dass ein Server sicher weiß, welche Variante der Client an das Modell weiterreicht. Ein fester Antwortvertrag würde Implementierungen berechenbarer machen und Integrationsaufwand senken.
Offener Standard statt proprietärer Agentenplattform
MCP entwickelt sich damit zu einer herstellerunabhängigen Integrationsschicht für Datenbanken, interne Anwendungen und On-Premises-Systeme. Unternehmen können Fachsysteme über definierte Schnittstellen anbinden und das verwendete Modell oder die Laufzeitumgebung später austauschen. Das verringert die Abhängigkeit von geschlossenen SaaS-Plattformen und proprietärer Middleware.
Der Nutzen entsteht allerdings nicht ohne Eigenaufwand. Identitätsverwaltung, Rechtekonzepte, Überwachung und sichere Tool-Definitionen bleiben Aufgaben des Betreibers. Wie wichtig kontrollierte Werkzeugaufrufe sind, zeigt auch AWS Dogwood gegen falsche Tool-Aufrufe.
Für eigene Agentenlösungen bietet die Roadmap dennoch eine belastbarere Grundlage. Zustandslose Server vereinfachen die Skalierung, Progressive Discovery kann Token-Kosten begrenzen und standardisierte Identitäten passen besser zu bestehenden Governance-Strukturen. Ergänzende Standards wie Agent Plugins 1.0 für portable KI-Agenten zeigen, dass sich rund um Agenten zunehmend ein offener Infrastruktur-Stack bildet.