Am 28. Juli 2026 hat MCP etwas getan, was Protokolle selten tun: Es hat Funktionen entfernt. Sessions auf Protokollebene und der Initialisierungs-Handshake sind weg. Ein Server muss keinen Zustand mehr über eine Verbindung hinweg halten und skaliert damit horizontal wie jede andere HTTP-Anwendung.
Am 22. August 2026 haben die Core Maintainer eine neue Roadmap mit fünf Schwerpunkten veröffentlicht. Der erste heißt „Agentic messaging primitives“ und scheint auf den ersten Blick in die andere Richtung zu weisen. Vorgesehen sind langlaufende Aufgaben, laufend übermittelte Ergebnisse und Eingriffe während der Ausführung. Über Webhooks und Channels sollen Server ihre Clients außerdem von sich aus benachrichtigen, damit diese nicht mehr regelmäßig den Status abfragen müssen.
Erst den Zustand raus, dann den Zustand rein. Für Teams, die MCP betreiben, steckt darin eine praktische Entscheidung: Welche Zustandsdaten gehören zur Verbindung, welche zum Auftrag? Und unter wessen Identität wird der Auftrag ausgeführt? Meine These: MCP übernimmt einzelne Funktionen einer Control Plane rund um die Agenten-Runtime. Was das heißt, steht unten.
Stand September 2026. Der zustandslose Protokollkern ist veröffentlicht. Tasks und Enterprise-Managed Authorization (Delegation von Berechtigungen im Unternehmen) sind offizielle Extensions, die Client und Server jeweils explizit unterstützen müssen. Webhooks, Progressive Discovery sowie weitergehende Vorhaben zur Agentenidentität und Delegation stehen auf der Roadmap. Die Einordnung als Control Plane (Steuerungsebene) ist die These dieses Artikels und keine offizielle Klassifizierung.
Das Versprechen von 2024 war deutlich kleiner
Als Anthropic MCP im November 2024 vorstellte, war die Aufgabe eng umrissen: ein offener Standard, der KI-Anwendungen mit Datenquellen und Werkzeugen verbindet, damit nicht für jede Kombination aus Modell und System ein eigener Konnektor entsteht. Daher die Analogie, die seitdem in jedem zweiten Vortrag auftaucht: USB-C für KI.
Dahinter steht ein Modell, das so alt ist wie das Web: Anfrage, Arbeit, Antwort. Ein Werkzeugaufruf ist eine Funktion mit JSON-Schema: Sie bekommt Parameter, sie liefert ein Ergebnis, sie ist fertig. Die USB-C-Analogie erklärt den einheitlichen Anschluss gut. Über den Lebenszyklus von Aufgaben und die Rechte autonomer Aufrufer sagt sie wenig aus.
Wer MCP noch nicht kennt: Die Grundlagen stehen in MCP-Server erklärt.
Der Rechnungsimport, der zwanzig Minuten braucht
Nehmen wir einen MCP-Server, der Rechnungen aus einem Altsystem in ein neues ERP überführt. Ein Lauf dauert etwa zwanzig Minuten. Nach der Hälfte findet der Abgleich vierzig Dubletten, und ohne eine Entscheidung geht es nicht weiter. Der Client verliert zwischendurch die Verbindung. Nachts um drei soll derselbe Import ohne anwesenden Nutzer laufen.
Mit einem reinen Anfrage-Antwort-Modell bleiben dafür drei Optionen, und alle drei haben Nachteile:
- Die Verbindung offenhalten. Bei längeren Läufen wird sie wegen unterschiedlicher Client-, Proxy- und Load-Balancer-Timeouts anfällig für Verbindungsabbrüche, unabhängig davon, ob der Server sie technisch halten könnte.
- Ein eigenes Job-Protokoll bauen. Ein Werkzeug liefert eine Job-ID, ein zweites fragt den Status ab. Das funktioniert, aber Status, Rückfragen und Abbruch folgen dann einer eigenen Konvention statt einem gemeinsamen Task-Modell.
- Die Arbeit in Einheiten zerlegen, die sicher unter allen relevanten Timeouts bleiben. Geht manchmal. Bei einem Abgleich mit Rückfrage nicht.
Genau hier entstehen die Kosten. Nicht in der Protokolltheorie, sondern in der Woche, die jemand mit Variante zwei verbringt, und in der Frage der Revision ein halbes Jahr später: Unter welcher Identität ist dieser Import um drei Uhr morgens gelaufen?
Der Aufruf bekommt einen Lebenszyklus
MCP Tasks lösen den ersten Teil, derzeit als offizielle Extension, die Client und Server jeweils explizit aushandeln. Sie machen langlaufende Arbeit nicht erstmals möglich, sie vereinheitlichen den Umgang damit. Die Roadmap sieht vor, Tasks nach der Reifephase in den Protokollkern zu übernehmen (SEP-2663). Statt zu blockieren, gibt der Server ein dauerhaftes Handle zurück: eine taskId, einen Status, eine Lebensdauer und ein empfohlenes Abfrageintervall. Der Task wird dauerhaft angelegt, bevor die Antwort rausgeht. Wenn der Client abstürzt und neu startet, fragt er mit derselben ID weiter.
Der Lebenszyklus ist überschaubar: working, input_required, completed, failed, cancelled. Der Client holt sich den Stand über tasks/get, liefert fehlende Eingaben über tasks/update nach und kann über tasks/cancel abbrechen. Der Server bestätigt die Abbruchanforderung. Das bedeutet aber nicht, dass er die Ausführung sofort beendet.
Der Task hat eine Adresse und einen Status. Die Rückfrage mitten im Lauf ist damit ein regulärer Zustand und kein Sonderfall.
Der interessanteste Zustand in dieser Liste ist input_required. Die Rückfrage nach den vierzig Dubletten ist damit kein Sonderfall mehr, den sich jedes Team selbst modelliert, sondern ein regulärer Zustand im Lebenszyklus der Aufgabe. Für den Nachtlauf heißt das: Der Auftrag bleibt bei ungeklärten Dubletten offen, bis eine berechtigte Person die Entscheidung nachreicht. Der Task bildet die Rückfrage ab, er ersetzt die fehlende Freigabe nicht.
Die Arbeit hat eine Adresse bekommen.
Heute ist Polling der Normalfall. Ein Server kann Statusänderungen zwar über notifications/tasks schicken, wenn der Client sich per subscriptions/listen dafür registriert hat, aber die Roadmap geht deutlich weiter: server-initiierte Ereignisse über Webhooks und Channels, dazu die Möglichkeit, laufende Arbeit von außen zu steuern. Beides ist geplant, aber noch nicht spezifiziert.
Ein Protokoll, das Ereignisse zustellt, laufende Arbeit unterbricht und umlenkt, wäre kein reiner Aufrufmechanismus mehr. Es wäre Koordinationsinfrastruktur. Beim Nachtlauf würde der Server die offene Dublettenfrage von sich aus melden, statt dass am Morgen jemand den Status abfragt.
Der Zustand gehört zur Aufgabe, nicht zur Verbindung
Keine Session heißt, jede Anfrage steht für sich. Jeder Serverprozess kann jede Anfrage beantworten. Autoscaling, rollierende Deployments und Load Balancing funktionieren wie bei jeder gewöhnlichen API, weil nirgendwo ein Prozess eine Unterhaltung im Arbeitsspeicher hütet, die beim Neustart verloren geht.
Ein Task heißt, der Zustand liegt nicht mehr implizit in einer Verbindung, sondern explizit in einem Objekt mit eigener Kennung, das spätere Requests unabhängig von der ursprünglichen Verbindung wieder adressieren können.
Beide Änderungen trennen zwei Dinge, die leicht verwechselt werden: den Zustand einer Verbindung und den Zustand der Arbeit. Ein zustandsloser Protokollkern erzwingt ausdrücklich keine zustandslose Anwendungsarchitektur.
In einem Satz: Der Zustand verschwindet nicht. Er wandert aus der Verbindung in ein eigenes Objekt.
Links hütet ein Prozess die Unterhaltung im Arbeitsspeicher. Rechts liegt der Stand in einem Objekt, das jeder Prozess adressieren kann.
Dieselbe Logik steckt in einer unscheinbaren Änderung aus dem Juli. Server-initiierte Anfragen wurden durch ein Muster namens Multi Round-Trip Requests ersetzt, damit Rückfragen an den Nutzer, im MCP-Jargon Elicitation, auch auf zustandslosen Servern funktionieren. Rückfragen bleiben möglich. Eine dauerhaft offene Verbindung ist dafür nicht mehr nötig.
Agenten brauchen eigene Identitäten
Die Autorisierung in MCP ist bislang auf die Freigabe durch einen Menschen ausgelegt, der im Browser auf „Zugriff erlauben“ klickt. Für interaktive Clients ist das genau richtig. Die Roadmap benennt sehr direkt, warum es nicht mehr reicht: immer mehr Aufrufer sind Agenten, die als Cloud-Workload mit eigener Identität laufen, im Auftrag eines Nutzers handeln, der gerade nicht da ist, oder engere Rechte an Sub-Agenten weiterreichen.
Zurück zu drei Uhr morgens. Läuft der Import unter einem Servicekonto mit langlebigem Token, stellt sich die nächste Frage: Sind dessen Rechte auf diesen Auftrag begrenzt?
Die Roadmap setzt dagegen auf bestehende Standards statt auf ein Eigengewächs:
- DPoP (RFC 9449) bindet ein Token an einen Schlüssel. Ein gestohlenes Token allein reicht einem Angreifer dann nicht mehr. Laut Roadmap wird die Integration noch finalisiert.
- Workload Identity Federation lässt einen Workload seine Identität gegenüber der eigenen Plattform nachweisen, statt ein dauerhaftes Geheimnis in einer Konfigurationsdatei zu parken.
- Token Exchange und der ID-JAG-Grant aus der Enterprise-Managed Authorization sind bereits als Extension verfügbar und regeln die Delegation im Unternehmenskontext. Die Weitergabe an Sub-Agenten ist noch nicht spezifiziert.
Hinzu kommt die Mitarbeit in den zuständigen IETF-Arbeitsgruppen, damit auch die zugrunde liegenden Standards entsprechend weiterentwickelt werden.
Trotzdem verändert sich die Rolle des Aufrufers im Berechtigungssystem. Ein autonomer Aufrufer wird zu einem Sicherheitsprinzipal mit eigener Identität und ist kein Skript mehr, das sich fremde Zugangsdaten ausleiht.
Progressive Discovery ist mehr als Token-Sparen
Das Vorhaben aus der Roadmap: Ein Server soll künftig einen kleinen Einstiegspunkt anbieten und mehr von seinem Katalog zeigen, je klarer die Aufgabe wird.
Die entscheidende Frage bei Progressive Discovery ist nicht das Token-Sparen, sondern wer über die Sichtbarkeit von Werkzeugen bestimmt. Bisher gilt: Der Client holt die Werkzeugliste und legt fest, was in den Kontext des Modells wandert. Progressive Discovery beteiligt den Server an der Entscheidung, welche Fähigkeiten wann überhaupt sichtbar werden. Der Client würde zusätzliche Werkzeuge damit auch während der Bearbeitung einer Aufgabe ermitteln. Das käme einer Aushandlung mit dem Server nahe. Wie diese ablaufen soll, lässt die Roadmap bislang offen.
Wie groß das Problem wird, hat Anthropic im November 2025 beziffert: 58 Werkzeuge aus fünf Servern kosten rund 55.000 Token, bevor der Nutzer den ersten Satz tippt. Das sind herstellereigene Zahlen und kein Leistungsnachweis für einen künftigen MCP-Mechanismus.
Control Plane, nicht Runtime
In Netzwerken und Cluster-Systemen trennt man seit langem zwei Ebenen. Die Data Plane transportiert die Pakete und erledigt die Arbeit. Die Control Plane entscheidet, wer was darf, wohin etwas geleitet wird, was gerade läuft und wie man es anhält.
Genau in diese Rolle wächst MCP gerade hinein. Nicht als zentrale Control Plane eines gesamten Systems, sondern als Protokoll für mehrere ihrer Funktionen am Rand der Agenten-Runtime. MCP transportiert weiterhin Werkzeugaufrufe und Ergebnisse und liegt damit nicht vollständig außerhalb des Ausführungspfads. „Control Plane“ ist hier eine Architekturmetapher und keine Klassifizierung im Kubernetes-Sinn.
Die eigentliche Agenten-Runtime bleibt bei den Frameworks und ist dort auch gut aufgehoben. Reasoning-Schleife, Gedächtnis, Planung, Scheduling, Modellaufrufe, Sandboxing, Wiederholungsstrategien. Nichts davon standardisiert MCP im Kern, und nichts davon sollte es standardisieren. MCP standardisiert die Schnittstelle der Runtime nach außen.
Oben die Funktionen, die MCP übernimmt. Unten die Runtime, die bei den Frameworks bleibt.
MCP oder A2A: Wer verantwortet die Ausführung?
Zwei Tage vor der MCP-Roadmap, am 20. August 2026, hat die Agentic AI Foundation die Arbeitsteilung im entstehenden Protokollstapel beschrieben. A2A standardisiert die Zusammenarbeit zwischen unabhängigen Agenten. MCP verbindet einen Agenten mit seinen Werkzeugen und seinem Kontext. Drei Tage zuvor, am 17. August, war A2A als Hosted Project in die AAIF aufgenommen worden. Beide Protokolle liegen damit unter einem Dach.
A2A hat für diese Zusammenarbeit längst eine Agent Card zum Auffinden von Agenten, Tasks mit eigener Kennung, Zwischenergebnisse, Fortschrittsmeldungen und die Möglichkeit, für Rückfragen oder Freigaben zu pausieren. Die zwei Tage später veröffentlichte MCP-Roadmap nennt ebenfalls langlaufende Tasks, Streaming, Steuerung, server-initiierte Ereignisse, Agentenidentität und Delegation. Die Merkmalslisten laufen sichtbar aufeinander zu.
Damit zurück zum Rechnungsimport. Der Server nimmt einen Auftrag an, arbeitet zwanzig Minuten, meldet Fortschritt, fragt mitten im Lauf nach einer Entscheidung und liefert am Ende ein Ergebnis. Von außen nähert er sich dem Interaktionsprofil eines Agenten, auch wenn intern weiterhin nur ein deterministischer Workflow läuft.
Genau deshalb ist die Dauer das falsche Unterscheidungsmerkmal, und die AAIF hat die Frage in demselben Text schon besser beantwortet: Die Grenze ergibt sich aus der Interaktion, nicht aus dem Code hinter dem Endpunkt. Bei MCP nutzt eine KI-Anwendung Werkzeuge und Kontext. Bei A2A übergeben unabhängige Agenten Arbeit, verhandeln über den Auftrag und entscheiden selbst, wie sie ihn intern bearbeiten. Dasselbe System kann beide Schnittstellen anbieten, und eine A2A-Fähigkeit mit einfacher Aufrufsemantik lässt sich als MCP-Werkzeug oder Ressource abbilden.
Der entscheidende Unterschied ist also nicht das Task-Modell, sondern wer die Ausführung verantwortet und wie viel Eigenständigkeit man der Gegenstelle zugesteht. Das ist eine Definition und keine technische Schranke. Genau das macht sie tragfähig und fragil zugleich. Tragfähig, weil sie sich nicht an Feature-Listen aufhängt, die ohnehin weiter konvergieren. Fragil, weil sie die Entscheidung an die Teams zurückgibt, die das bauen. Nichts hindert ein Team daran, einen Agenten als Werkzeug anzubieten, und das Protokoll wird es nicht merken.
Als Architekturheuristik, nicht als harte Spezifikationsgrenze:
| Situation | Sinnvolle Schnittstelle |
|---|---|
| Klar definierter Aufruf mit bekanntem Input und Output | MCP Tool |
| Dieselbe Tool-Beziehung, aber dauerhaft, fortsetzbar oder mit Rückfrage | MCP Task, sofern beide Seiten die Extension unterstützen |
| Unabhängige Gegenstelle verantwortet die Ausführung, verhandelt über den Auftrag und entscheidet intern über die Bearbeitung | A2A |
Zusammengefasst, was davon heute steht und was noch Ankündigung ist:
| Entwicklung | Status | Folge für Teams |
|---|---|---|
| Sessions und Initialisierungs-Handshake entfallen | Im Core umgesetzt | Ein Remote-Server lässt sich transportseitig wie ein gewöhnlicher horizontal skalierbarer HTTP-Dienst betreiben. |
| Der Aufruf bekommt mit Tasks einen Lebenszyklus | Optionale Extension, Übernahme in den Core geplant | Langlaufende Arbeit wird adressierbar, aber nur gegenüber Clients, die die Extension unterstützen. |
| Benachrichtigungen statt Statusabfragen, dazu Steuerung laufender Arbeit | Roadmap | Noch nicht als verfügbare Funktion voraussetzen. Polling bleibt vorerst der Normalfall. |
| Workload-Identität über DPoP, Federation und Token Exchange | Teils Extension, Delegation an Sub-Agenten auf der Roadmap | Langlebige Servicekonto-Token als Übergangslösung behandeln. |
| Progressive Discovery von Werkzeugkatalogen | Roadmap, Mechanismus offen | Große Kataloge vorerst clientseitig begrenzen und die Entwicklung verfolgen. |
Was daraus praktisch folgt
Wer langlaufende Operationen implementiert, sollte zunächst prüfen, ob sich dafür Tasks nutzen lassen. Einen proprietären Fallback braucht es nur dort, wo die vorgesehenen Clients die Extension noch nicht unterstützen.
Wer MCP-Server betreibt, kann sie transportseitig wie gewöhnliche, horizontal skalierbare HTTP-Dienste behandeln. Dauerhafter Arbeitszustand liegt separat in Tasks oder anderen expliziten Objekten, samt Persistenz, Autorisierungsprüfung und gegebenenfalls externer Job-Infrastruktur.
Wer die Identitätsverwaltung plant, sollte langlebige Servicekonto-Token als Übergangslösung behandeln und den Weg über DPoP und Workload Identity Federation im Blick behalten. Delegation an Sub-Agenten ist noch nicht fertig, aber die Richtung steht.
Wer viele Server einbindet, sollte Progressive Discovery verfolgen. Die Roadmap sieht vor, Werkzeugkataloge schrittweise offenzulegen. Der konkrete Mechanismus ist noch offen.
MCP standardisiert nicht, wie ein Agent denkt. Es beginnt zu standardisieren, wie seine Aufgaben in verteilten Systemen verwaltet werden.
