Alle Depeschen

DepescheWerkzeugeneu

MCP wird zustandslos: Die kommende Spezifikation streicht Sessions, Handshake, Roots und Sampling

Die nächste Revision des Model Context Protocol räumt tief auf. Der Draft-Changelog gegenüber der bisherigen Fassung 2025-11-25 entfernt die protokollseitigen Sessions samt Mcp-Session-Id-Header aus dem Streamable-HTTP-Transport und streicht den initialize-Handshake komplett: Jede Anfrage trägt Protokollversion und Client-Fähigkeiten künftig selbst im _meta-Feld, ein neues Pflicht-RPC server/discover übernimmt die Versionsaushandlung. Server-initiierte Anfragen wie roots/list, sampling/createMessage und elicitation/create weichen dem Muster „Multi Round-Trip Requests“; Roots, Sampling und Logging sind als Features abgekündigt, die experimentellen Tasks wandern aus dem Kern in eine offizielle Erweiterung. InfoWorld berichtet, der Release Candidate sei für den 28. Juli 2026 angesetzt.

Der zentrale Schnitt sind zwei Vorschläge. SEP-2567 entfernt die protokollseitigen Sessions und den Mcp-Session-Id-Header aus dem Streamable-HTTP-Transport; die Listen-Endpunkte tools/list, resources/list und prompts/list variieren damit nicht mehr je Verbindung. Server, die Zustand über mehrere Aufrufe hinweg brauchen, sollen dafür explizite, selbst vergebene Handles nutzen und diese als gewöhnliche Werkzeug-Argumente durchreichen. SEP-2575 – im Projekt-Repository am 11. Mai 2026 zusammengeführt – macht das Protokoll dann vollständig zustandslos: Der Handshake aus initialize und notifications/initialized entfällt, stattdessen trägt jede Anfrage Protokollversion und Client-Fähigkeiten in ihren _meta-Feldern (io.modelcontextprotocol/protocolVersion, io.modelcontextprotocol/clientCapabilities). Passt die Version nicht, antwortet der Server mit UnsupportedProtocolVersionError. Als Ersatz für die Aushandlung müssen Server ein neues RPC server/discover anbieten, über das sie unterstützte Versionen, Fähigkeiten und Identität bekanntgeben.

Mit dem Zustand fällt auch das Rückkanal-Modell. Der HTTP-GET-Endpunkt sowie resources/subscribe und resources/unsubscribe weichen einem einzelnen langlebigen POST-Antwortstrom namens subscriptions/listen, für den Clients gezielt Benachrichtigungstypen abonnieren (toolsListChanged, promptsListChanged, resourcesListChanged, resourceSubscriptions). Anfrage-bezogene Meldungen wie notifications/progress laufen weiterhin über den Antwortstrom der jeweiligen Anfrage. Gestrichen werden ping, logging/setLevel und notifications/roots/list_changed; die Log-Stufe setzt der Client nun je Anfrage über io.modelcontextprotocol/logLevel im _meta-Feld. Ebenfalls entfernt: die Wiederaufnahme abgebrochener SSE-Ströme samt Last-Event-ID-Header – reißt der Antwortstrom, ist die laufende Anfrage verloren und muss mit neuer Request-ID wiederholt werden.

Server-initiierte Anfragen ersetzt SEP-2322 durch das Muster „Multi Round-Trip Requests“ (MRTR). Statt selbst eine Anfrage an den Client zu stellen, liefert der Server ein InputRequiredResult zurück, dessen Feld inputRequests die benötigten Zusatzinformationen benennt; der Client wiederholt daraufhin die ursprüngliche Anfrage und hängt die Antworten als inputResponses an. Damit alle Beteiligten die zwei Fälle unterscheiden können, tragen sämtliche Ergebnisse jetzt ein Pflichtfeld resultType mit den Werten „complete“ oder „input_required“ – Ergebnisse älterer Server ohne dieses Feld müssen Clients als „complete“ behandeln.

Abgekündigt, aber noch funktionsfähig, sind Roots, Sampling und Logging (SEP-2577). Der Changelog nennt dafür konkrete Migrationswege: Verzeichnisse und Dateien über Werkzeug-Parameter, Ressourcen-URIs oder Server-Konfiguration statt über Roots; direkte Anbindung an die APIs der Modellanbieter statt Sampling; Ausgabe nach stderr oder OpenTelemetry statt Logging. Zusätzlich rückt der ältere HTTP+SSE-Transport in den Deprecated-Status, und die dynamische Client-Registrierung nach RFC 7591 weicht den Client-ID-Metadaten-Dokumenten. Neu ist dazu eine ausdrückliche Lebenszyklus- und Abkündigungs-Regel mit den Zuständen Active, Deprecated und Removed sowie einer Mindestfrist von zwölf Monaten – das ist die eigentliche Beruhigung für Betreiber: Nichts von dem Gestrichenen verschwindet über Nacht.

Am Rand, aber für Kosten und Latenz relevant, stehen zwei Caching-Regeln. Ergebnisse von tools/list, prompts/list, resources/list, resources/read und resources/templates/list müssen künftig die Felder ttlMs (Frischehinweis in Millisekunden) und cacheScope („public“ oder „private“) tragen, damit Clients zwischenspeichern statt zu pollen. Und Server sollen ihre Werkzeugliste in deterministischer Reihenfolge zurückgeben – ausdrücklich, um clientseitiges Caching zu ermöglichen und die Trefferquote der Prompt-Caches zu erhöhen. Die Einschätzung, warum der Umbau überhaupt kommt, fasst der von InfoWorld zitierte Muskan Bandta (ZopDev) so zusammen: „The session-based model made sense when MCP servers were local processes on a developer’s laptop. In production, it became an operational tax.“