MCP 2026-07-28: der zustandslose Kern und die Grenzen seiner Kompatibilität

Worum es geht

Stand: 25. Oktober 2026. Die am 28. Juli 2026 angekündigte MCP-Revision 2026-07-28 verändert den Protokolllebenszyklus. Vor einem Upgrade das versionierte Änderungsprotokoll, die Kompatibilitätsregeln, die Spezifikationen der Erweiterungen und das Register abgekündigter Funktionen erneut prüfen; die Release-Ankündigung gibt einen Überblick, ist aber keine vollständige Spezifikation des Nachrichtenaustauschs.

Die Revision entfernt initialize, notifications/initialized und HTTP-Sitzungen auf Protokollebene, einschliesslich Mcp-Session-Id. Jede Anfrage deklariert ihre Version und die Fähigkeiten des Clients in _meta. Server müssen server/discover implementieren; Clients können es zur vorgängigen Ermittlung der Servereigenschaften aufrufen oder direkt eine andere Anfrage senden. «Optionale Discovery» beschreibt die Wahlmöglichkeit des Clients, keine Ausnahme für Server. Diese Unterscheidungen folgen der Versionierungsspezifikation.

Warum es wichtig ist

Der Verbindungsaufbau liefert keinen Kontext mehr für nachfolgende Operationen. Ein Deployment muss den Transportzustand vom Anwendungszustand unterscheiden, etwa dem eines lange laufenden Auftrags. Bestehende Clients, die den früheren Handshake verwenden, benötigen einen kompatiblen Verarbeitungsweg; allein die Änderung einer Versionszeichenfolge wandelt ihre Nachrichten nicht um.

Die Release-Ankündigung beschreibt die betriebliche Motivation: Anfragen können ohne Sitzungsbindung verschiedene Serverinstanzen erreichen. Dieser Vorteil entbindet die Anwendung nicht von der Verantwortung, ihren eigenen dauerhaften Zustand zu speichern.

So wird es angewendet

• Annahmen zum Lebenszyklus erfassen. Impliziten Verbindungskontext durch Anfragemetadaten ersetzen. Für einen Zustand, der mehrere Aufrufe überdauert, explizite Anwendungsreferenzen als Tool-Argumente bereitstellen. Bei Unterstützung älterer Clients einen separaten Verarbeitungsweg für sie beibehalten.
• Zwischenergebnisse verarbeiten. Multi Round-Trip Requests ersetzen unabhängige, vom Server initiierte Anfragen. Ein input_required-Ergebnis fordert eine Eingabe an; der Client wiederholt die ursprüngliche Operation mit inputResponses. Gewöhnliche Ergebnisse verwenden resultType: "complete". Antworten früherer Versionen, denen das Feld fehlt, werden als abgeschlossen behandelt.
• HTTP-Integration aktualisieren. Header für die Methode und, soweit zutreffend, den Namen implementieren und subscriptions/listen für ausdrücklich abonnierte Änderungsbenachrichtigungen verwenden. Fortschrittsmeldungen zu einer Anfrage bleiben auf deren ursprünglichem Antwortstream. Die Wiederaufnahme von SSE und die erneute Zustellung entfallen: Zur Wiederherstellung ist eine neue Anfrage mit neuer ID erforderlich, mit Schutzmassnahmen auf Anwendungsebene gegen wiederholte Seiteneffekte.
• Cache-Metadaten implementieren. Das Änderungsprotokoll verlangt ttlMs und cacheScope für bestimmte Listen- und Ressourcenergebnisse. Aktualität und Erlaubnis zur gemeinsamen Nutzung getrennt beurteilen; keines von beiden bedeutet, dass jede Antwort öffentlich zwischengespeichert werden darf.
• Erweiterungen ausdrücklich deklarieren. Erweiterungen geben ihre Unterstützung über Capability-Maps bekannt, sind standardmässig deaktiviert und müssen von Entwicklern ausdrücklich aktiviert werden. Tasks wechseln aus dem experimentellen Kern in eine offizielle Erweiterung. Die Unterstützung auf beiden Seiten bestätigen, statt sie aus der Kernversion abzuleiten.
• Funktionslebenszyklen verfolgen. Active, Deprecated und Removed sind getrennte Zustände. Die übliche Mindestfrist für die Abkündigung beträgt zwölf Monate; die Richtlinie erlaubt eine genehmigte Sicherheitsausnahme mit mindestens neunzig Tagen. Den Eintrag der jeweiligen Funktion prüfen, bevor ihre Entfernung geplant wird.

Stolpersteine

Zustandslosigkeit nicht als Verbot von Streaming-Antworten oder dauerhaften Anwendungsdaten verstehen. Nicht voraussetzen, dass jede Erweiterung in jedem konformen SDK enthalten ist: Die Unterstützung von Erweiterungen ist optional und entwickelt sich unabhängig. Schliesslich rechtfertigt die Entfernung des alten Handshakes in dieser Revision nicht, Kompatibilitätsverhalten zu löschen, solange ältere Clients darauf angewiesen sind.