Die Stateful-Falle, die MCP ausbremste
Das ursprüngliche Protokoll von MCP legte eine erhebliche architektonische Einschränkung auf: inhärente Zustandsabhängigkeit. Zuvor initiierte ein Client die Interaktion mit einer initialize-Anfrage an einen MCP-Endpunkt. Der Server erstellte daraufhin eine eindeutige session ID und gab diese zurück – ein Token, das für die gesamte nachfolgende Client-Server-Kommunikation entscheidend war. Jede Folgeanfrage musste diesen Identifikator enthalten.
Dieses Design schuf einen grundlegenden Fehler für skalierbare Bereitstellungen. Die obligatorische session ID band den Client an die spezifische Serverinstanz, die den initialize-Aufruf ursprünglich verarbeitet hatte. Dies durchbrach standardmäßige Load-Balancing-Paradigmen. Wenn ein Load Balancer, etwa ein Round-Robin-Router, eine nachfolgende Anfrage an eine andere Instanz weiterleitete, fehlte diesem Server jeglicher Datensatz der Sitzung. Das Ergebnis war ein lähmender 400 "session not found"-Fehler, der die Client-Operationen stoppte. Ebenso gingen bei einem Absturz einer Instanz sofort alle aktiven Sitzungszustände verloren, was zu sofortigen Fehlern bei Client-Anfragen führte.
Entwickler waren gezwungen, komplexe und ineffiziente Workarounds zu implementieren, um diese Probleme zu mildern. Gängige Lösungen umfassten den Einsatz von sticky sessions, die sicherstellten, dass ein Client konsistent dieselbe Serverinstanz erreichte. Ein anderer Ansatz beinhaltete die Bereitstellung von Shared-State-Speichern, wie etwa einer Redis-Instanz, um Sitzungsdaten über alle Server hinweg zu zentralisieren und zu synchronisieren. Beide Methoden führten zu unnötigem operativen Overhead, erhöhten die Netzwerklatenz und steigerten die Infrastrukturkosten erheblich. Dies waren protokollbedingte Belastungen, keine freien Entscheidungen.
Standardmäßig zustandslos: Ein Protokoll wird neu geboren
Die neue Spezifikation von MCP, '2026-07-28', führt einen radikalen Wandel ein. Zwei Schlüsselvorschläge, SEP-2575 und SEP-2567, definieren den Kern des Protokolls neu. SEP-2575 eliminiert den initialize- und initialized-Handshake, während SEP-2567 den MCP-Session-Id-Header und die damit verbundene session auf Protokollebene entfernt.
Diese Änderungen verwandeln einen mehrstufigen Tool-Aufruf in eine einzelne, in sich geschlossene HTTP-Anfrage. Zuvor war der Kontext fragmentiert; nun werden alle notwendigen Informationen in einem meta-Feld innerhalb des JSON-Bodys übertragen. Dieses Design macht jede Anfrage unabhängig und spiegelt die Prinzipien zustandsloser HTTP-Kommunikation wider.
Die Ausrichtung auf Standard-HTTP-Infrastruktur ist nun vollständig. Neue Header, MCP-Method und MCP-Name, enthalten jetzt kritische Routing-Informationen. Dies ermöglicht es Netzwerkkomponenten wie Gateways, Firewalls und Rate Limitern, Entscheidungen zu treffen, ohne das JSON-Payload parsen zu müssen. Eine solche Effizienz ist entscheidend für die Performance, insbesondere auf Cloudflare.
Das Protokoll erfordert keine Durable Objects mehr, um MCP zu nutzen, was die Bereitstellung vereinfacht. Dienste können bei Leerlauf auf null skalieren, was die Betriebskosten erheblich senkt und die Bereitstellungsoptionen erweitert. Dieser Wandel eliminiert die Probleme von Sticky Sessions oder gemeinsam genutzten Redis-Instanzen und macht MCP standardmäßig wirklich zustandslos.
Intelligentere Infrastruktur und Anwendungsstatus
Zustandslosigkeit eröffnet massive Vorteile bei der Bereitstellung. Serverless-Plattformen wie Cloudflare Workers und Google Cloud Run skalieren nun bei Leerlauf auf null, was die Betriebskosten drastisch senkt. Server müssen keine persistenten Verbindungen mehr aufrechterhalten, wodurch die Notwendigkeit entfällt, ständig aktive Instanzen zur Speicherung des Sitzungsstatus vorzuhalten. Dies verändert die Bereitstellung der Infrastruktur grundlegend.
Das Protokoll belastet das State-Management nicht mehr. Stattdessen wird der Status zu einem Anliegen auf Anwendungsebene. Tools können explizite Handles erstellen, wie zum Beispiel eine basket_id oder browser_id. Das Modell übergibt diesen Bezeichner dann bei späteren Tool-Aufrufen als gewöhnliches Argument zurück. Dies gibt Entwicklern mehr Flexibilität und ermöglicht es ihnen, den Status genau nach Bedarf zu verwalten, anstatt sich an protokollbedingte Muster anzupassen.
MCP verwendet HTTP-inspiriertes Caching für eine verbesserte Effizienz auf Client-Seite. Neue time to live- und cache scope-Hinweise informieren Clients über die Aktualität von Tool-, Prompt- und Ressourcenlisten. Dies ermöglicht es Clients, Antworten sicher zwischenzuspeichern und dauerhafte Verbindungen für Updates zu vermeiden. Für weiterführende Informationen zu robustem, zustandslosem API-Design lesen Sie Statelessness in API Design: Understanding & Examples - Unkey. Diese Hinweise stellen sicher, dass Clients genau wissen, wie lange Daten für Benutzer gültig bleiben.
Gefällt Ihnen der Artikel? Erhalten Sie jeden Morgen einen wie diesen per E-Mail.
eine E-Mail pro Tag · Abmeldung mit zwei Klicks · kein Tracking durch Dritte
Neue Muster für komplexe Interaktionen
Komplexe Interaktionen folgen nun einem klaren, Client-gesteuerten Muster. Zuvor sendete der Server unaufgeforderte Folgefragen, was ein Sicherheitsrisiko darstellte. Die neue Spezifikation verhindert dies. Bei Interaktionen mit mehreren Schritten gibt der Server ein input_required-Ergebnis zurück.
Dieses Ergebnis enthält eine serialisierte request_state-Payload, die den gesamten Kontext für die ausstehende Aktion kapselt. Ein Client empfängt input_required, fragt den Benutzer (z. B. "Sind Sie sicher?") und initiiert dann die ursprüngliche Anfrage erneut. Der Client fügt die Antwort des Benutzers bei und spiegelt den request_state wider. Dies stellt sicher, dass der Client die Interaktion jederzeit steuert. Jede Serverinstanz kann die fortgesetzte Anfrage übernehmen, was die Zustandslosigkeit stärkt.
Lang andauernde Vorgänge nutzen die nun offizielle 'tasks'-Erweiterung. Diese Funktion hat den experimentellen Status verlassen. Bei einer Aufgabe wie der Bearbeitung einer Rückerstattung bestätigt der Server die Anfrage sofort. Er gibt eine Antwort zurück, die anzeigt, dass der Vorgang läuft, wodurch eine Blockierung der Verbindung verhindert wird.
Clients verfolgen den Fortschritt dann asynchron. Sie können mittels tasks/get pollen oder sich über subscriptions/listen anmelden. Dies ermöglicht den Abruf des Endergebnisses, sobald die lang andauernde Aufgabe abgeschlossen ist. Dieses Design macht dauerhafte Verbindungen während langer Berechnungen überflüssig und verbessert die Protokolleffizienz sowie die Ausfallsicherheit.
Häufig gestellte Fragen
Was war das Hauptproblem mit dem alten zustandsbehafteten MCP?
Das alte Protokoll erforderte Session-IDs, die Clients an bestimmte Serverinstanzen banden. Dies erschwerte das Load Balancing, erforderte komplexe Workarounds wie Sticky Sessions oder Redis und machte das System anfällig, da ein Neustart des Servers den Session-Status verlieren konnte.
Wie löst das neue zustandslose MCP diese Probleme?
Es entfernt Session-Handshakes und IDs vollständig (Spezifikation 2026-07-28). Jede Anfrage ist in sich geschlossen, was ein standardmäßiges Round-Robin-Load-Balancing, verbesserte Ausfallsicherheit und die Möglichkeit für Server ermöglicht, auf null zu skalieren, wodurch Kosten gesenkt werden.
Wie wird der Status im neuen MCP verwaltet, wenn das Protokoll zustandslos ist?
Der Status wird nun auf Anwendungsebene verwaltet, nicht auf Protokollebene. Entwickler können ein Tool ein explizites Handle (z. B. 'browser_id') erstellen lassen, das das Modell in nachfolgenden Aufrufen zurückgibt – ein flexibles Muster, das in Standard-HTTP-APIs üblich ist.
Was passiert mit lang andauernden Tool-Aufrufen ohne eine dauerhafte Verbindung?
Die neue Spezifikation erhebt die 'tasks'-Erweiterung zu einem offiziellen Feature. Bei einem lang andauernden Job kann der Server sofort eine Task-ID zurückgeben, und der Client kann diese Aufgabe dann pollen oder abonnieren, um Fortschrittsaktualisierungen und das Endergebnis asynchron zu erhalten.