Programmierung und Softwareentwicklung

Die neue MCP-Version baut das Protokoll für den Betrieb ohne Sitzungen um

Die Version 2026-07-28 des Model Context Protocol ist zu einem zustandslosen Protokoll geworden. Dadurch können MCP-Server auf Cloudflare Workers ohne dedizierte Infrastruktur zur Sitzungsverwaltung betrieben werden. Die Version umfasst Änderungen an Interaktionen über mehrere Runden, der Autorisierung und dem Lebenszyklus von Funktionen sowie aktualisierte SDK-Pakete und einen Migrationspfad für bestehende Anwendungen.

2026-08-06
5 Min. Lesezeit
281 Aufrufe
certi.news Editorial Team
Die neue MCP-Version baut das Protokoll für den Betrieb ohne Sitzungen um

Model Context Protocol (MCP) ist in der Version 2026-07-28 nach einer Neufassung seines Kerns, seines Interaktionsmodells und der zugehörigen SDK-Pakete vollständig zustandslos geworden. Cloudflare zufolge ermöglicht diese Änderung den Betrieb von MCP-Servern in einem gewöhnlichen Worker, ohne dedizierte Infrastruktur zur Aufrechterhaltung von Protokollsitzungen. Gleichzeitig werden die betriebliche Komplexität und die Kosten zusätzlicher Komponenten reduziert.

Die neue Spezifikation wurde vergangene Woche zusammen mit aktualisierten SDK-Paketen für TypeScript, Python, Go und C# veröffentlicht. Laut Cloudflare können Server nun eine Anfrage empfangen, ein Tool, eine Eingabeaufforderung oder eine Ressource ausführen und anschließend das Ergebnis zurückgeben, ohne zwischen den Anfragen eine Protokollsitzung zu speichern.

Verzicht auf obligatorische Sitzungen

Frühere Versionen begannen mit dem Austausch von initialize und initialized, um eine Sitzung zu erstellen, wobei über den Header Mcp-Session-Id eine ID zugewiesen werden konnte. Jede nachfolgende Anfrage musste auf den mit dieser Sitzung verbundenen Zustand zugreifen. Das stellte Umgebungen mit automatischer Skalierung vor Herausforderungen und erforderte, dass Bereitstellungen aktive Sitzungen auslaufen ließen oder verschoben. Der Verlust einer aktiven Serverinstanz konnte dazu führen, dass der Client die Verbindung erneut herstellte oder die Sitzung ausfiel.

Die neue Version entfernt den obligatorischen Handshake, den Header Mcp-Session-Id und Sitzungen aus dem grundlegenden Anfragepfad. Jede Anfrage enthält die Protokollversion sowie die erforderliche Identität und die Fähigkeiten des Clients. Der Aufruf von server/discover zur Überprüfung des Servers vor der Ausführung einer weiteren Anfrage ist nun optional.

Das bedeutet nicht, dass zustandsbehaftete Anwendungen nicht mehr benötigt werden. Cloudflare weist darauf hin, dass Durable Objects weiterhin geeignet sind, wenn die Anwendung selbst einen koordinierten Zustand benötigt. MCP setzt Durable Objects jedoch nicht mehr voraus, um über das Protokoll zu kommunizieren, und Server, die eine anfragegebundene Verarbeitung benötigen, können auf Workers skaliert werden.

Interaktionen über mehrere Runden statt offener Streams

Die Version gestaltet den Mechanismus der elicitation neu. Dabei benötigt der Server zusätzliche Informationen, bevor er eine Anfrage abschließen kann, etwa die Zustimmung zur Bereitstellung einer Version in der Produktion oder die Bestätigung einer Rückerstattung. Zuvor stützten sich vom Server initiierte Anfragen auf einen offenen Stream.

Mit dem Mechanismus Multi Round-Trip Requests kann der Server ein Ergebnis mit dem Namen input_required zurückgeben, das die benötigten Daten erläutert. Der Client sammelt die Antwort und versucht die Operation anschließend mit diesen Daten erneut, ohne dass eine der beiden Seiten zwischen den Anfragen eine Transportsitzung aufrechterhalten muss. Cloudflare beschreibt diese Änderung als inkompatibel mit dem bisherigen Verfahren, aber operativ einfacher.

MCP-Anfragen für HTTP-Infrastruktur verständlich machen

Die neue Spezifikation verlangt die beiden Header Mcp-Method und Mcp-Name in Streamable-HTTP-Anfragen. Dadurch können ein Gateway, ein Ratenbegrenzer oder eine Web Application Firewall erkennen, ob die Anfrage ein Tool aufruft oder eine Ressource liest, ohne den vollständigen JSON-RPC-Inhalt analysieren zu müssen.

Die Spezifikation fügt den Ergebnissen von tools/list, prompts/list, resources/list und resources/read außerdem die Hinweise ttlMs und cacheScope hinzu. Zudem legt sie eine deterministische Reihenfolge für Tool-Indizes fest, wodurch diese wiederverwendet und die Stabilität des Prompt-Caches bei einer erneuten Verbindung gewahrt werden kann.

Änderungen an Autorisierung und Funktionslebenszyklus

Die neue Spezifikation bevorzugt vorab registrierte Clients, wenn bereits eine Beziehung zwischen Client und Server besteht. Für die dynamische Registrierung verwendet sie anschließend Client-Identitätsmetadaten-Dokumente, CIMD, während Dynamic Client Registration oder DCR zur Fallback-Option wird. DCR wurde für neue Anwendungen als veraltet angekündigt und soll nach dem Sommer 2027 entfernt werden.

Die Spezifikation übernimmt außerdem den Mechanismus aus RFC 9207 zur Angabe des Ausstellers und schreibt vor, dass die primäre Serveradresse in Autorisierungs- und Token-Anfragen gemäß RFC 8707 als Ressource verwendet wird. Cloudflare zufolge setzt der Workers OAuth Provider diese Anforderungen für MCP-Server auf Workers um.

Die Spezifikation verfügt nun über einen formalen Lebenszyklus, der Funktionen als aktiv, veraltet oder entfernt einstuft. Eine veraltete Funktion muss mindestens 12 Monate lang verfügbar bleiben, bevor sie entfernt wird. Zu den in dieser Version als veraltet angekündigten Funktionen gehören Roots, Sampling, Logging, DCR und das alte HTTP+SSE-Verfahren. MCP Apps und Enterprise-Managed Authorization wurden zu Erweiterungen, während Tasks in das Erweiterungs-Framework verschoben wurden, um einen Pfad für lang laufende und zuverlässige Vorgänge bereitzustellen.

Migrationspfad und Verfügbarkeit

Die Schnittstelle createMcpHandler verlässt den experimentellen Status und wird Teil des offiziellen MCP-TypeScript-SDKs. Cloudflare stellt außerdem weiterhin eine auf Workers ausgerichtete Schnittstelle innerhalb des Agents SDK bereit. Das Unternehmen unterstützte zudem die Umstellung des TypeScript-SDKs von Node.js auf Web Standards, um die Kompatibilität mit Bun, Deno und Cloudflare Workers zu verbessern.

Clients können migrieren und dabei die Kompatibilität mit älteren Spezifikationen beibehalten. Der Endpunkt /mcp akzeptiert das neue Protokoll sowie zustandslose Anfragen von Streamable-HTTP-Clients, die die Version 2025 verwenden. Dadurch können die meisten Clients die Verbindung ohne Änderungen an der Konfiguration erneut herstellen. Server, die auf alten Sitzungen, Server-zu-Client-Anfragen oder unabhängigen Streams basieren, benötigen dagegen einen vorsichtigeren Migrationspfad, etwa den Betrieb eines zustandslosen Pfads neben dem alten Pfad, bis die aktiven Sitzungen ausgelaufen sind.

Cloudflare zufolge ist die neue Spezifikation für Clients und Server auf seiner Plattform verfügbar. Ein zustandsloser MCP-Server kann auf einem Worker betrieben und über den Workers OAuth Provider abgesichert werden. Nach Angaben des Unternehmens nutzt der Code Mode MCP Server für die Cloudflare-API diesen Ansatz und erreicht Tausende Anfragen pro Sekunde sowie Milliarden von Tool-Aufrufen.

Nachrichtenquelle
Cloudflare Blog
Originalquelle öffnen ↗
c
Autor

certi.news Editorial Team

Das Wichtigste

Die am 28.07.2026 veröffentlichte Version des Model Context Protocol hat das Protokoll so umgestaltet, dass es ohne obligatorische zustandsbehaftete Sitzungen funktioniert. Dadurch lassen sich die Server leichter auf Cloudflare Workers betreiben, ohne eine eigene Infrastruktur zur Sitzungsverwaltung. Die Version umfasst Änderungen an mehrstufigen Anfragen, der Autorisierung und dem Lebenszyklus von Funktionen sowie Migrationspfade für bestehende Anwendungen.

  • Die neue Version entfernt den obligatorischen Handshake und den Header Mcp-Session-Id aus dem grundlegenden Anfragepfad; jede Anfrage enthält die für ihre Ausführung erforderlichen Informationen.
  • Zustandslose MCP-Server können auf einem gewöhnlichen Worker betrieben werden, während Durable Objects weiterhin geeignet sind, wenn Anwendungen einen koordinierten Zustand benötigen.
  • Der Mechanismus für Multi Round-Trip Requests ermöglicht es dem Server, über ein input_required-Ergebnis zusätzliche Informationen anzufordern, ohne zwischen den Anfragen eine Transportsitzung aufrechtzuerhalten.
  • Die Header Mcp-Method und Mcp-Name sind nun bei Streamable-HTTP-Anfragen erforderlich, damit Gateways, Ratenbegrenzungen und Firewalls die Anfragen besser verstehen können.
  • Dynamic Client Registration ist nun eine Fallback-Option und wurde für neue Anwendungen zur Ausmusterung vorgesehen; die Entfernung ist nach Sommer 2027 geplant.
  • Aktualisierte SDK-Pakete für TypeScript, Python, Go und C# sind verfügbar. Clients können migriert werden und in bestimmten Fällen die Kompatibilität mit älteren Spezifikationen beibehalten.

FAQ

Was hat sich in der MCP-Version vom 28.07.2026 geändert?

MCP ist im grundlegenden Protokollpfad vollständig zustandslos geworden; obligatorische Sitzungen, der Handshake und der Header Mcp-Session-Id wurden entfernt.

Sind Durable Objects weiterhin erforderlich, um MCP auf Cloudflare Workers zu betreiben?

Nein. MCP erfordert für die Kommunikation über das Protokoll keine Durable Objects mehr. Sie bleiben jedoch für Anwendungen geeignet, die einen koordinierten Zustand benötigen.

Müssen ältere Anwendungen sofort migriert werden?

Clients können migriert werden und dabei die Kompatibilität mit älteren Spezifikationen beibehalten. Server, die auf älteren Sitzungen oder unabhängigen Abläufen basieren, müssen den zustandslosen Pfad jedoch möglicherweise neben dem alten Pfad betreiben, bis die aktiven Sitzungen ausgelaufen sind.

Aus derselben Kategorie

Das könnte Sie interessieren

Alle Nachrichten anzeigen