Cloudflare verschiebt MCP auf einen zustandslosen Request-Pfad. Das klingt zunächst wie eine Protokollbereinigung. Für Teams, die Remote-Tools betreiben, ist es aber eine Architekturänderung: Eine Tool-Anfrage muss künftig keine langlebige MCP-Session und damit auch keinen zustandsbehafteten Serverprozess mehr mitbringen.
Der bisherige Betriebsballast: eine Session pro Verbindung
Frühere MCP-Transporte begannen mit initialize/initialized. Server konnten eine Mcp-Session-Id vergeben; Folgeanfragen mussten dann genau diesen Zustand wiederfinden. Autoscaling, Deployments und Ausfälle wurden dadurch unnötig an aktive Sessions gekoppelt. Auf Serverless-Plattformen bedeutete das zusätzliche Koordination, obwohl viele Tool-Aufrufe schlicht Anfrage rein, Ergebnis raus sind.
Die Spezifikation 2026-07-28 entfernt den verpflichtenden Handshake, den Mcp-Session-Id-Header und Protokoll-Sessions aus dem Kernpfad. Jede Anfrage bringt ihre Protokollversion, Client-Identität und Fähigkeiten selbst mit. server/discover bleibt möglich, ist aber optional.
Was sich für den Betrieb konkret ändert
| Vorher | Jetzt |
|---|---|
| Transport-Session muss erhalten oder migriert werden. | Ein isolierter Request kann Tool, Prompt oder Resource ausführen und antworten. |
| Stateful Hosting war für das MCP-Protokoll praktisch nötig. | State bleibt nur dort nötig, wo die Anwendung ihn wirklich benötigt. |
| Gateways mussten JSON-RPC-Bodies analysieren, um Tool-Aufrufe zu erkennen. | Mcp-Method und Mcp-Name machen Methode und Tool im HTTP-Layer sichtbar. |
Das ist auch für Security und Observability relevant. Rate Limiter, WAFs und Gateways können Regeln oder Metriken auf Tool-Ebene nun aus HTTP-Headern ableiten, statt beliebige JSON-Nutzlasten zu parsen. Das macht aus MCP kein automatisch sicheres Protokoll — aber es setzt die Kontrollfläche dorthin, wo Betreiber sie bereits haben.
Elicitation ohne offenen Stream
Eine besonders praktische Folge betrifft Rückfragen. Braucht ein Deployment-Tool vor dem Release eine Bestätigung, musste ein Server zuvor einen offenen Stream für elicitation/create halten. Neu sind Multi Round-Trip Requests: Der Server liefert input_required, der Client holt die Eingabe ein und wiederholt den Aufruf. Zwischen den Runden muss keine Transport-Session fortbestehen.
Die entscheidende Trennung lautet: MCP braucht keinen State mehr; die Anwendung kann ihn weiterhin brauchen. Wer einen laufenden Job, Replay oder serverinitiierte Interaktion modelliert, sollte diesen Zustand bewusst als Anwendungszustand behandeln — nicht als unvermeidliche Folge des Tool-Protokolls.
Migration: Nicht nur McpAgent ersetzen
Cloudflare deklariert McpAgent als deprecated und feature-frozen und empfiehlt für den request-orientierten Pfad createMcpHandler. Das ist keine mechanische Umbenennung. Funktionen wie RPC, Streams, Replay und serverinitiierte Requests bleiben sessionabhängig und verlangen eine parallele Migrationsentscheidung.
- Tools klassifizieren: Ist ein Aufruf wirklich zustandslos, oder hängt er an Job-, Nutzer- oder Freigabezustand?
- HTTP-Policies nachziehen:
Mcp-MethodundMcp-Namefür Tool-spezifische Limits, Logs und WAF-Regeln prüfen. - Rückfragen testen: Freigabe- und Eingabe-Flows mit
input_requiredals Wiederholungslogik testen. - Legacy explizit halten: Für Streams und Replay nicht versehentlich den alten Zustandsbedarf wegabstrahieren.
Einordnung
Der substanzielle Fortschritt ist nicht ein neues SDK-Symbol. MCP wird für den üblichen Tool-Aufruf näher an das gebracht, was HTTP-Infrastruktur gut kann: einzelne, überprüfbare und horizontal skalierbare Requests. Das senkt nicht nur Plattformkomplexität; es macht Tool-Traffic auch für die bestehende Betriebs- und Sicherheitskette besser sichtbar.
Quelle
Cloudflare Engineering: The next generation of MCP (veröffentlicht am 6. August 2026, 13:00 UTC). Ergänzend: Cloudflare Changelog zur Agents SDK v0.20.0 und die Migrationsdokumentation.
Leave a Reply