mcp stateless agent-infrastructure oauth api-gateway opentelemetry

Zustandsloses MCP in der Spezifikation vom 2026-07-28: Welche Änderungen gibt es für die Agent-Infrastruktur?

Die neue MCP-Version entfernt Sessions, fügt Routing-Header, input_required-Rundreisen sowie eine strengere OAuth-Implementierung hinzu. Was das für Gateways, Skalierbarkeit und Sicherheit bedeutet.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 28. Okt. 20268 Min. Lesezeit1883 Wörter

Quellen: MCP Goes Stateless: Why the New Spec Changes Agent Infrastructure

Das Model Context Protocol hat sich schnell weiterentwickelt. Anfangs konzentrierten sich die Diskussionen auf die Verbindung von KI-Anwendungen mit Tools und Daten. Seitdem wurden OAuth-Autorisierungen, entfernte Server, umfangreiche Protokolländerungen, Registrierungen, Client ID Metadata Documents sowie Unternehmensautorisierungen eingeführt. Die Spezifikation vom 2026-07-28 verändert etwas Grundlegendes: Das Protokoll selbst wird zustandslos.

Die Initialisierungsabläufe sowie die sessions auf Protokollebene existieren nicht mehr. Ein Client muss nicht länger an die Serverinstanz gebunden bleiben, die seine Verbindung akzeptiert hat. Jeder Anfrage liegen ausreichende Informationen bei, um eigenständig bearbeitet zu werden, und jede kompatible Instanz kann darauf antworten.

Es könnte als eine Anpassung im Transportbereich durchgehen, doch die architektonischen Auswirkungen sind tiefergreifend. Fernserver können sich wie jede cloud-basierte HTTP-Dienstleistung verhalten und hinter gewöhnlichen Load Balancern, API-Gateways, WAFs, serverlosen Plattformen sowie skalierbaren Container-Flotten stehen, ohne dass spezielle Session-Mechanismen für MCP erforderlich wären.

Durch die Überarbeitung kommen weitere Verbesserungen hinzu: Standard-Routing-Header, entdeckte Ergebnisse, die gekacht werden können, Mehrfach-Request-Verfahren, strengere Autorisierungsregeln, OpenTelemetry-Konventionen sowie ein formelles Erweiterungsmodell. MCP erscheint als Infrastruktur weniger eigenartig, was wohl zu den deutlichsten Anzeichen für Reife gehört. Im Folgenden werden die Änderungen erläutert, warum Statelessness in der Produktion wichtig ist und welche Auswirkungen dies auf Sicherheit, Gateways sowie den allgemeinen Agenten-Runtime hat.

Warum Sessions schaden

MCP begann mit einem bescheidenen Problem: Es sollte einer KI-Software eine standardisierte Methode bieten, um mit Tools, Ressourcen und externen Systemen umzugehen. Für lokale Clients und Server funktionierte das problemlos. Remote MCP änderte alles. Als die Server in Containern, Kubernetes-Clustern, serverlosen Plattformen und Cloud-Infrastrukturen betrieben wurden, verursachten Sessions auf Protokollebene die üblichen Probleme bei verteilten Systemen.

Ein Client führte einen Initialisierungsabgleich durch, der Server konnte eine Mcp-Session-Id zuweisen, und jede nachfolgende Anfrage musste diese Beziehung beibehalten. In großem Maßstab konnte das bedeuten:

Load-Balancer-Stickiness
gemeinsame Session-Speicher
Failover, das Sessions versteht
lange Lebensdauer der Verbindungen
ergänzende Lebenszyklusverwaltung

Nichts davon ist unmöglich zu verwalten, denn verteilt arbeitende Systeme bewältigen das bereits seit Jahrzehnten. Die Frage ist vielmehr, ob MCP die Probleme überhaupt schaffen musste – und mit 2026-07-28 lautet die Antwort zunehmend nein.

Die neue Spezifikation streicht komplett die initialize- und notifications/initialized-Prozeduren, die sessions auf Protokollebene sowie Mcp-Session-Id. Die Anfragen enthalten alles, was zur Verarbeitung benötigt wird. Konzeptionell ändert sich die Architektur wie folgt:

Jede kompatible Instanz kann die nächste Anfrage verarbeiten. Das passt weitaus besser zu Kubernetes, Containern, serverlosen Funktionen, Auto-Scaling, Edge-Infrastruktur sowie herkömmlichem Round-Robin-Load-Balancing.

Es geschieht bereits in der Praxis. Cloudflare hat seine MCP-Server auf dieses Modell umgestellt und für jede Anfrage einen neuen, zustandslosen Server erstellt. Google bezeichnet das Ende der „sticky sessions“ sowie der gemeinsam genutzten Session-Infrastruktur als bedeutenden Vorteil bei der Skalierung. Der AWS AgentCore Gateway unterstützt nun neben früheren MCP-Versionen auch das neue Protokoll. Somit handelt es sich dabei um Teil des heutigen Bereitstellungsmodells und nicht um eine theoretische Architektur.

Der Zustand verschwindet nicht

Hier ist eine Unterscheidung wichtig. Das Entfernen von MCP-Sessions hindert Anwendungen nicht daran, Zustände beizubehalten. Das bedeutet, der Anwendungs-Zustand sollte nicht im Transportmechanismus versteckt werden. Nehmen wir einen Agenten, der einen Arbeitsbereich erstellt:

create_workspace()
  |
  v
workspace_id = ws_123

Eine spätere Anfrage kann das Ergebnis ausdrücklich benennen:

update_workspace( workspace_id = "ws_123" )

Die erste Anfrage könnte auf Server A und die zweite auf Server C landen. Die Anwendung besitzt weiterhin einen Zustand, verfügt nun jedoch über einen expliziten Identifikator und ist nicht mehr von einer unsichtbaren Verbindung zwischen Client und einem Serverprozess abhängig.

Protokollzustand und Anwendungsstatus sind unterschiedliche Konzepte. Ein expliziter Anwendungsstatus lässt sich leichter speichern, überprüfen, autorisieren, ablaufen lassen und analysieren. Zudem haben agentbasierte Systeme den Vorteil, dass der Agent direkt mit dem Identifikator arbeiten und ihn zwischen verschiedenen Tools sowie Workflow-Schritten übertragen kann.

Routing-Header

Der Zustandslosigkeitsansatz löst ein Infrastrukturproblem – doch eine weitere Änderung kann für Unternehmensumgebungen genauso wichtig sein. MCP standardisiert nun HTTP-Header, die die laufenden Operationen beschreiben. Beispielsweise:

MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: delete_workspace

Früher musste ein Zwischenagent möglicherweise den JSON-RPC-Payload öffnen, um herauszufinden, was der Agent wollte. Jetzt ist die Information auf der HTTP-Ebene sichtbar, was einige interessante Möglichkeiten eröffnet.

Sicherheitsteams haben Grund zur Sorge. Agenten haben Zugriff auf leistungsstärkere Tools, und das Gateway wird zu einem geeigneten Ort, um Richtlinien zwischen Absicht und externer Wirkung durchzusetzen. All das beseitigt jedoch nicht die Notwendigkeit von Agent-Harnesses oder kontrollierenden Mechanismen auf Anwendungsseite. Im Gegenteil: Es schafft klarere Trennlinien zwischen Protokoll, Gateway, Harness sowie den dahinterliegenden Systemen.

Eingabe anfordern ohne Sitzung

Der Zustandslosigkeitsansatz wirft ein offensichtliches Problem auf: Was passiert, wenn ein Server weitere Informationen benötigt, bevor er eine Operation abschließen kann? Stellen Sie sich einen zerstörerischen Aufruf vor:

delete_environment(“production”)

Der Server könnte zunächst eine Bestätigung wünschen. Das Halten einer bidirektionalen Sitzung nur für diesen Austausch würde einen Großteil der Vorteile der Zustandslosigkeit zunichtemachen.

Die Lösung in der Spezifikation sind mehrfache Round-Trip-Anfragen (MRTR). Eine Sitzung hält die Interaktion nicht mehr am Leben. Stattdessen gibt der Server ein input_required-Ergebnis zurück, das angibt, was benötigt wird. Der Austausch verläuft in etwa wie folgt:

Menschliche Genehmigung, zusätzliche Authentifizierung, fehlende Parameter, Richtlinienüberprüfungen sowie ähnliche interaktive Abläufe können alle in einem Zustandslosigkeitsanfragemodell untergebracht werden. Das ist insbesondere bei hochriskanten Aktionen von Agenten relevant. Die Fähigkeit, ein Tool aufzurufen, gibt einem Agenten keinen unbegrenzten Zugriff, und sensible Operationen können vor der Ausführung einen Entscheidungspunkt hinzufügen.

Caching und Überwachbarkeit

Einige der weniger auffälligen Änderungen können im großen Maßstab von Bedeutung sein. Dazu gehören insbesondere die Auflistung von Operationen:

tools/list
prompts/list
resources/list
resources/read

Es können nun Cache-Details wie ttlMs und cacheScope zurückgegeben werden, und die Auflistung der Tools sollte in einer deterministischen Reihenfolge erfolgen. Das klingt nach einer gewöhnlichen HTTP-Optimierung, doch auch KI-Systeme profitieren davon: stabile Tool-Definitionen können das Caching von Prompts beim LLM verbessern, während Tools, die in wechselnder Reihenfolge ankommen oder wiederholt entdeckt werden müssen, eine kleine Protokollbesonderheit in zusätzliche Latenz und Tokenkosten umwandeln.

Die Spezifikation dokumentiert außerdem, wie der OpenTelemetry-Context mit vertrauten Feldern übertragen werden kann:

traceparent
tracestate
baggage

Das ist ein weiteres Beispiel dafür, wie MCP in Richtung der Infrastrukturen driftet, die DevOps- und Plattformteams bereits kennen. Das Ziel sollte nicht darin bestehen, einen separaten Observability-Stack nur für KI-Protokolle zu entwickeln. Stattdessen sollte es darum gehen, die Aktivitäten der Agenten innerhalb der Systeme sichtbar zu machen, die die Organisationen bereits betreiben.

Identität wird immer wichtiger

Stateless-Anfragen verringern die Bedeutung der Identität nicht. Im Gegenteil: Sie machen es notwendig, bei jeder einzelnen Anfrage alles richtig zu machen. Die neue Spezifikation setzt MCPs Entwicklung in Richtung der etablierten OAuth- und OpenID Connect-Praktiken fort. Dazu gehört die Validierung des Ausstellers, um Angriffe durch Verwechslungen mit Autorisierungsservern zu verhindern, sowie eine strengere Verknüpfung von Zugangsdaten.

Die Spezifikation formalisiert außerdem eine bereits bestehende Entwicklung: Die dynamische Client-Registrierung wird zugunsten von Client-ID-Metadatendokumenten deaktiviert. CIMD hat sich als sauberere Lösung durchgesetzt, während DCR aus Kompatibilitätsgründen weiterhin verwendet wird – und der Text macht das nun unmissverständlich klar. Es handelt sich dabei um ein weiteres Zeichen für Reifung, da MCP auf ein privates Identitätsystem verzichtet und sich weiterhin auf Standards konzentriert, die bereits im Web genutzt werden. Für die Bereitstellung von Unternehmensagenten wird dies umso wichtiger, je mehr MCP von wenigen vom Benutzer autorisierten Integrationen zu einer großen Anzahl von Agenten, Clients, Gateways und Tools wächst.

Die Registrierung ist nur ein Teil der Autorisierung. Im Unternehmensumfeld stellt sich die schwierigere Frage, welche Agenten auf welche Funktionen zugreifen dürfen: Hunderte von Agenten, die Hunderte von Diensten aufrufen, erzeugen ein komplexes Governance-Problem der Art N×M. Zwei Mechanismen – Enterprise-Managed Authorization (EMA) und Identity Assertion Authorization Grants (ID-JAG) – lenken diese Entscheidungen in Richtung zentraler Unternehmensrichtlinien. Ein Unternehmensidentitätsanbieter hilft dabei zu entscheiden, ob ein Agent Zugang erhält, sodass die einzelnen MCP-Server nicht nacheinander die Zustimmung der Benutzer einholen müssen.

Stateless MCP ersetzt dieses Modell nicht. Es vertieft vielmehr die Trennung: Transportzustand, Client-Identität, Autorisierungsrichtlinien und Anwendungsstatus sind unterschiedliche architektonische Aspekte.

Was bleibt außerhalb des Kerns

Ein aussagekräftiger Aspekt der Neuveröffentlichung ist das, was MCP weglässt oder umverteilt. Roots, Sampling und Logging verlassen das Kernmodell, und der ältere HTTP+SSE-Transport wird durch Streamable HTTP ersetzt. Gleichzeitig wird ein formelles Erweiterungsframework eingeführt, sodass Funktionen wie Tasks als Erweiterungen hinzugefügt werden können, ohne den Protokollkern zu vergrößern. Das bedeutet eine klarere Trennung:

MCP muss nicht zum gesamten Agenten-Runtime werden. Das Steuerungssystem behält weiterhin die umfassendere Ausführungsumgebung unter Kontrolle, und MCP bietet eine standardisierte Methode dafür, dass diese Umgebung mit externen Funktionen interagieren kann. Ein ausgereiftes Protokoll wird nicht nur durch das definiert, was es hinzufügt, sondern auch durch das, was es bewusst anderswo belässt.

Stateless bedeutet nicht vertrauenswürdig

Ein stateless MCP-Server lässt sich einfacher skalieren, doch „stateless“ bedeutet nicht automatisch Vertrauenswürdigkeit: Jeder Anfrage muss weiterhin eine Sicherheitsgrenze überschreiten. Prompt-Injection oder manipulierter Kontext können weiterhin dazu führen, dass Agenten falsch gesteuert werden. Tools können weiterhin übermäßige Berechtigungen haben, Anmeldeinformationen können weiterhin falsch konfiguriert sein, und ein Sicherheitsvorfall in der Lieferkette kann weiterhin bösartige Server oder Tools einbringen.

Was sich ändert, ist, dass die Architektur übersichtlicher wird. Anstatt Transport-Sessions als Teil des Sicherheitsmodells zu betrachten, können Schutzmaßnahmen darauf ausgerichtet sein, wer der Aufrufer nachweislich ist, welche Richtlinien das Gateway durchsetzt und welche Berechtigungen jedes Tool gewährt. Fügen Sie explizite Autorisierungen sowie explizite Ressourcenidentifikatoren hinzu, validieren Sie Eingaben, verlangen Sie eine menschliche Genehmigung für sensible Aktionen, erfassen Sie Telemetriedaten zur Überprüfung und halten Sie auch den Agenten unter Kontrolle.

Ein subtiler Punkt: Klientenmetadaten sind nicht automatisch eine Identität. Was ein Klient in den Anfragemetadaten über sich selbst angibt, kann nicht wie eine durch OAuth oder ein anderes vertrauenswürdiges Verfahren kryptografisch festgelegte Identität bewertet werden. Eine einfachere Routierung und Überprüfung des MCP-Traffics ermöglicht es den Sicherheitsteams, die Einhaltung der Vorgaben für das Protokoll zu stärken, ohne Metadaten fälschlicherweise als Vertrauensgrundlage zu betrachten.

Der größere Überblick

Der wesentliche Wandel am 2026-07-28 ist einfach: MCP ist zustandslos. Die wichtigere Frage ist, was das ermöglicht. MCP-Anfragen verhalten sich eher wie gewöhnliche HTTP-Aufgaben. Server können horizontal skaliert werden, ohne dass eine Session-Bindung besteht. Gateways verstehen MCP-Operationen über Standard-Header. Die Entdeckung von Ressourcen kann in Cache gespeichert werden. Interaktive Workflows werden über mehrfache Round-Trip-Anfragen fortgesetzt. Die Autorisierung entwickelt sich weiterhin in Richtung der bewährten OAuth-Praxis, die Überwachung kann OpenTelemetry nutzen, und Erweiterungen lassen Raum für Weiterentwicklungen, ohne den Kern in den gesamten Agenten-Runtime umzuwandeln.

Einzelne Aspekte erscheinen wie Verbesserungen des Protokolls, doch zusammen sagen sie mehr aus. MCP begann damit, Probleme der Verbindbarkeit zu lösen. Remote MCP brachte das Ökosystem dazu, sich mit Identität und Autorisierung auseinanderzusetzen. CIMD sowie die Unternehmensautorisierung richten sich nun auf die Governance, während stateless MCP sich mit Betriebsfähigkeit und Skalierbarkeit befasst. Das Protokoll wird immer weniger exotisch und passt zu Infrastrukturen, deren Aufbau, Sicherung, Überwachung und Betrieb bereits bekannt sind. Für etwas, das sich so schnell entwickelt, könnte es genau darum gehen, zu einer langweiligen Infrastruktur zu werden.