MCP, was ohne Sitzung übrig bleibt

Ein Handshake ist eine kleine Sache mit großer Wirkung. Zwei Gegenstellen tauschen einmal aus, wer sie sind und was sie können, und danach kann jede folgende Nachricht kurz sein, weil beide Seiten den Kontext schon haben. Genau das hat das Model Context Protocol seit November 2024 getan, und genau das ist in der Fassung 2026-07-28 gestrichen.

Der Verzicht klingt nach einer Optimierung für Rechenzentren. Er ist eine Entscheidung darüber, wo Zustand liegen darf, und er verschiebt Arbeit von den Servern zu den Clients. Dieser Text geht die Änderungen der Reihe nach durch, mit den Stellen aus der Spezifikation, an denen sie stehen.

Beide Fassungen nebeneinander

Die Tabelle stellt die letzte Fassung mit Sitzung neben die erste ohne. Die Abschnitte danach gehen die Zeilen einzeln durch.

Was bisher galt

Bis einschließlich der Fassung 2025-11-25 lief eine Verbindung so ab: Der Client schickt initialize, der Server antwortet mit seinen Fähigkeiten, der Client bestätigt mit notifications/initialized. Über HTTP konnte der Server dabei eine Sitzung vergeben, sichtbar als Header Mcp-Session-Id, die der Client fortan mitschickte. Ein zweiter Kanal stand offen: Per HTTP GET konnte der Client einen dauerhaften Ereignisstrom öffnen, über den der Server von sich aus Anfragen stellen durfte. Riss die Verbindung, ließ sich der Strom über Last-Event-ID an der Abbruchstelle wieder aufnehmen.

Für den Betrieb hieß das: Anfragen desselben Clients mussten auf derselben Instanz landen, oder alle Instanzen brauchten einen gemeinsamen Sitzungsspeicher. Wer vor den Server einen Übergang stellte, musste in die Nachrichten hineinsehen, um zu wissen, was durchgeht. Das ist der Aufwand, gegen den sich die neue Fassung richtet.

Was jetzt in jeder Anfrage steht

Der Handshake entfällt ersatzlos, ebenso die Sitzung. Was einmal ausgetauscht wurde, reist jetzt bei jedem Aufruf mit. Über HTTP sieht ein Tool Call so aus, hier gekürzt aus dem Trans­port­ab­schnitt der Spezifikation:

POST /mcp HTTP/1.1
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_weather

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "location": "Seattle, WA" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "ExampleClient", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Drei Dinge sind daran neu. Erstens die Angaben im Feld _meta, die früher aus dem Handshake kamen. Zweitens die Header Mcp-Method und Mcp-Name, die Werte aus dem Nachrichtenkörper spiegeln, damit ein Lastverteiler routen kann, ohne die Nachricht zu lesen. Drittens die Pflicht, dass beide Angaben übereinstimmen. Tun sie es nicht, muss der Server mit 400 Bad Request und dem Fehlercode -32020 ablehnen.

Diese dritte Regel ist die interessanteste, weil sie eine Angriffsfläche schließt, die mit der zweiten erst entsteht. Sobald ein Übergang nach dem Header entscheidet und der Server nach dem Inhalt handelt, gibt es zwei Wahrheiten über dieselbe Anfrage. Die Spezifikation begründet die Prüfpflicht genau damit. Wer eine Regel „dieser Mandant darf dieses Tool nicht“ am Übergang durchsetzt, muss sicher sein, dass der Server dasselbe liest.

Für Tool-Parameter gibt es dieselbe Spiegelung als Wahlmöglichkeit: Ein Server kann einzelne Parameter über x-mcp-header als Header Mcp-Param-{Name} ausweisen lassen, etwa eine Region. Werte, die sich nicht als reines ASCII darstellen lassen, werden dabei in einer eigenen Base64-Schreibweise übertragen.

Aushandeln ohne Aushandlung

Ohne Handshake gibt es keinen Moment, in dem sich beide Seiten auf eine Fassung einigen. Die Ver­sio­nie­rungs­seite (externe Seite, modelcontextprotocol.io) sagt das unmiss­ver­ständ­lich: Einen Handshake zum Aushandeln gibt es nicht. Jede Anfrage nennt ihre Fassung, und der Server nimmt sie an oder lehnt sie ab. Lehnt er ab, antwortet er mit UnsupportedProtocolVersionError und listet auf, was er kann. Der Client sucht sich daraus etwas aus und stellt die Anfrage erneut.

Wer es vorher wissen will, ruft server/discover. Diese Methode muss jeder Server anbieten, jeder Client darf sie benutzen, keiner muss. Damit ist der Handshake zur Wahlmöglichkeit geworden.

Die eigentliche Umkehr: der Server fragt nicht mehr

Die tiefste Änderung steht nicht bei den Headern. Bisher konnte ein Server den Client um etwas bitten, während er an einer Aufgabe arbeitete: um eine Modellantwort (Sampling), um eine Rückfrage an den Menschen (Elicitation), um die Liste der zugänglichen Verzeichnisse (Roots). Solche Anfragen liefen über den offenen Ereignisstrom. Ohne dauerhaften Kanal gibt es diesen Weg nicht mehr.

An seine Stelle tritt ein Muster mit dem Namen Multi Round-Trip Requests. Der Server antwortet auf die Anfrage mit einem Zwischenergebnis, das sagt, was ihm fehlt:

{
  "resultType": "input_required",
  "inputRequests": {
    "confirm": {
      "type": "elicitation",
      "message": "Delete 3 files?",
      "schema": { "type": "boolean" }
    }
  },
  "requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
}

Der Client besorgt die Antwort und stellt die ursprüngliche Anfrage noch einmal, diesmal mit den Antworten und dem zurückgereichten requestState. Der Server verpackt darin, was er sich merken muss, weil er es sich nicht mehr merken darf. Was das für die Sicherheit heißt, steht weiter unten bei den drei Arten von Zustand.

Daraus folgt eine kleine, leicht zu übersehende Pflicht: Jedes Ergebnis hat jetzt ein Feld resultType. Ergebnisse von Servern älterer Fassungen, denen das Feld fehlt, müssen Clients als abgeschlossen behandeln.

Für Benach­rich­ti­gungen über Änderungen, etwa wenn sich die Tool-Liste ändert, gibt es weiterhin einen langlebigen Strom. Er wird nur anders geöffnet: mit einer Anfrage subscriptions/listen, deren Antwort selbst der Strom ist. Der Client meldet dabei an, welche Arten von Meldungen er hören will.

Was der Betrieb gewinnt

Drei Punkte, die zusammen den Anlass für die ganze Umstellung bilden.

Beliebige Verteilung. Ohne Sitzung darf jede Anfrage auf jeder Instanz landen. Die Ankündigung (externe Seite, blog.modelcontextprotocol.io) formuliert es als das Ende einer Sonderbehandlung: Was bisher haftende Zuordnung, gemeinsamen Sitzungsspeicher und Paketinspektion brauchte, kommt jetzt mit einem schlichten Lastverteiler aus, der die Anfragen der Reihe nach auf die Instanzen verteilt.

Caching. Ergebnisse von Listenabfragen bekommen künftig zwei Pflichtfelder, ttlMs als Hinweis auf die Haltbarkeit und cacheScope mit den Werten public oder private. Das ist die Übertragung von Cache-Control auf das Protokoll. Zusätzlich sollen Server ihre Tool-Liste in stabiler Reihenfolge ausgeben, weil das die Trefferquote im Prompt-Cache der Modelle erhöht.

Nachvollziehen. Für die Weitergabe von Ablaufverfolgung sind die W3C-Schlüssel traceparent, tracestate und baggage in _meta festgelegt. Damit ist ein Tool Call über Systemgrenzen hinweg messbar, mit vorhandener Technik statt mit protokolleigener.

Was verloren geht

Die Wiederaufnahme. Der Satz aus dem Trans­port­ab­schnitt (externe Seite, modelcontextprotocol.io) ist so knapp wie seine Folge: Ein Ereignisstrom lässt sich über Last-Event-ID nicht mehr fortsetzen. Reißt die Verbindung während einer laufenden Anfrage, ist die Anfrage verloren, und der Client muss sie mit neuer Kennung neu stellen. Bei einem Tool, das Sekunden braucht, ist das eine Fußnote. Bei einem Aufruf, der Minuten läuft und Nebenwirkungen hat, ist es eine Entwurfsfrage: Wiederholbarkeit muss jetzt in der Anwendung stecken, oder die Arbeit läuft als Task mit eigener Kennung, deren Stand der Client abfragt.

Das Abbruchsignal. Über HTTP gibt es keine Abbruchmeldung mehr. Das Schließen des Antwortstroms ist das Signal, und der Trans­port­ab­schnitt (externe Seite, modelcontextprotocol.io) macht daraus eine Pflicht: Der Server muss das Schließen als Abbruch genau dieser Anfrage behandeln. Für einen Server heißt das, dass er auf geschlossene Verbindungen achten muss, wenn er lange Arbeiten nicht ins Leere laufen lassen will.

Zustandsloses Protokoll, zustandsbehaftete Anwendung

Zustandslos heißt in der Spezifikation etwas Bestimmtes. Der Abschnitt dazu (externe Seite, modelcontextprotocol.io) verlangt, dass alles, was zur Bearbeitung einer Anfrage nötig ist, in der Anfrage selbst steht. Über die Anwendung dahinter sagt das nichts. Ein Warenkorb, ein offener Browser oder eine Daten­bank­trans­ak­tion bleiben erlaubt, und die Freigabe-Ankündigung (externe Seite, blog.modelcontextprotocol.io) sagt in einem Satz, wie: Wer Zustand über mehrere Aufrufe braucht, lässt ein Tool eine ausdrückliche Kennung ausgeben, ein Handle, und das Modell reicht es als Argument zurück.

Genau genommen gibt es danach drei Arten von Zustand, und jede hat einen anderen Ort.

Der Protokollzustand ist das, was früher der Handshake festhielt: Fassung, Fähigkeiten, Kennung des Clients. Er steht jetzt in jeder Anfrage, und ein Server darf sich nicht auf eine frühere stützen. Das gilt ausdrücklich auch für stdio, wo ein laufender Prozess bisher wie eine Sitzung wirkte: Nach der Spezifikation (externe Seite, modelcontextprotocol.io) darf ein Server aus derselben Verbindung oder demselben Prozess nicht schließen, dass ein Gespräch oder eine Sitzung fortgesetzt wird.

Der Zustand einer Rückfrage reist durch den Client. Braucht ein Server mitten im Aufruf eine Bestätigung, packt er alles, was er für die Fortsetzung wissen muss, in requestState, und der Client reicht das Feld unverändert zurück. Die Spezifikation (externe Seite, modelcontextprotocol.io) nennt den Zweck: Ein Server kann so zusätzliche Angaben anfordern, ohne selbst irgendeinen Zustand zu halten. Damit wird aus dem Gedächtnis des Servers eine Eingabe von außen, und so behandelt die Spezifikation das Feld auch. Der Server muss es als vom Angreifer kontrolliert ansehen, denn ein bösartiger oder übernommener Client könnte es verändern, um das Verhalten des Servers zu verbiegen, Berech­ti­gungs­prü­fungen zu umgehen oder seine Logik durch­ein­an­der­zu­bringen. Beeinflusst das Feld Berechtigungen, Zugriffe oder Geschäftslogik, ist eine Inte­gri­täts­si­che­rung Pflicht, etwa per HMAC oder AEAD. Gegen Wiederverwendung empfiehlt die Spezifikation, den angemeldeten Nutzer, eine kurze Ablaufzeit und einen Fingerabdruck der ursprünglichen Anfrage mit hineinzuschreiben. Und wo ein Zustand höchstens einmal eingelöst werden darf, muss der Server das weiterhin selbst festhalten.

Der Fachzustand über mehrere Aufrufe bleibt beim Server. Ein Handle ist dabei nichts, was das Protokoll kennt; die Tool-Seite (externe Seite, modelcontextprotocol.io) hält fest, dass ihm der Begriff eines Zustands-Handles fremd ist. Auf der Leitung ist es eine gewöhnliche Zeichenkette im Ergebnis und ein gewöhnliches Argument im nächsten Aufruf. Im Beispiel dort legt ein Tool einen Warenkorb an und gibt dessen Kennung zurück, und der Server legt den Inhalt des Warenkorbs unter diesem Schlüssel ab und schlägt ihn bei jedem Aufruf nach.

Daraus folgt, was dort nicht ausgesprochen wird: Laufen mehrere Instanzen hinter einem Lastverteiler, muss dieser Speicher für jede erreichbar sein. Die Freigabe-Ankündigung (externe Seite, blog.modelcontextprotocol.io) verspricht, dass jede Anfrage hinter einem schlichten Lastverteiler auf jeder Instanz landen kann, ohne gemeinsamen Speicher, und das gilt für den Protokollkern. Der gemeinsame Speicher, den früher die Sitzung brauchte, entfällt also für das Protokoll und bleibt für die Anwendung, sobald sie sich etwas merkt.

Für den Entwurf von Handles gibt die Tool-Seite vier Hinweise, als Empfehlung ohne Pflicht. Die Berechtigung wird bei jedem Aufruf gegen das Handle geprüft, denn wer die Kennung kennt, ist damit noch nicht berechtigt; bei einem Server ohne Anmeldung ist die Kennung selbst der Schlüssel und braucht genug Zufall, etwa eine UUIDv4, und eine begrenzte Lebensdauer. Die Kennung bleibt undurchsichtig, damit niemand sie zerlegt oder errät. Die Lebensdauer steht in der Beschreibung des Tools, das sie anlegt, damit das Modell sie kennt, bevor es Zustand erzeugt. Und eine abgelaufene Kennung liefert einen Fehler, der das sagt, damit das Modell eine neue anlegen kann.

Dass die Kennung durch das Modell läuft, sehen die Betreuer als Vorteil. Nach ihrer Erfahrung (externe Seite, blog.modelcontextprotocol.io) funktioniert das besser als ein Sitzungszustand, der im Transport versteckt ist, weil das Modell die Kennung sieht und sie von Tool zu Tool weiterreichen kann. Eine Messung dazu nennen sie nicht. Die Kehrseite ist ein Fehlerbild, das es vorher nicht gab: Ein Modell kann eine Kennung verwechseln, abschneiden oder erfinden. Zeigt sie ins Leere, fängt das der vorgesehene Ablauffehler. Verwechselt es zwei gültige Kennungen, meldet niemand einen Fehler.

Den Zustand des Gesprächs hält ohnehin keiner der Server. Die Architekturseite ordnet ihn dem Host zu, also dem Programm, in dem das Modell läuft: Der vollständige Gesprächsverlauf bleibt nach der Architekturseite (externe Seite, modelcontextprotocol.io) beim Host. Wie sich die drei Rollen Host, Client und Server aufteilen, erklärt Agenten und Harness, Kapitel 02.

Wer nach dem Umstieg nicht mehr miteinander spricht

Die Ver­sio­nie­rungs­seite (externe Seite, modelcontextprotocol.io) führt eine Matrix über alle Kombinationen aus alter und neuer Gegenstelle. Zwei Zeilen darin lauten schlicht „Fails“: ein neuer Client an einem alten Server, und ein alter Client an einem neuen Server. Für den zweiten Fall gilt der Satz: Alte Clients haben keinen Weg nach vorn. Sie schicken initialize, und ein rein moderner Server kennt diese Methode nicht.

Der Ausweg heißt Zweigleisigkeit. Ein Server darf beide Zeitalter bedienen und entscheidet anhand der ersten Anfrage, welches gemeint ist. Ein Client darf erst modern anfragen und beim Fehlschlag prüfen, ob die Fehlerantwort selbst modern aussieht. Wichtig ist dabei eine Feststellung, die Fehlversuche spart: Welches Zeitalter gilt, ist eine Eigenschaft des Servers und hängt an keiner einzelnen Anfrage. Wer es einmal weiß, soll es sich merken.

Die offiziellen Bibliotheken nehmen einen Teil davon schon ab. Clients, die die neue Fassung sprechen, fallen auf den alten Handshake zurück, sobald sie auf einen Server der Fassung 2025-11-25 oder älter treffen; ein Server in Python bedient ab der Hauptversion 2 beide Fassungen an einer Adresse. Bei TypeScript und Go spricht ein Server die neue Fassung erst, wenn man den Transport ausdrücklich darauf einstellt (Beleg (externe Seite, blog.modelcontextprotocol.io)). Die Zeile „Fails“ für einen neuen Client an einem alten Server trifft also eine reine Neuumsetzung, wer die Bibliothek nimmt, ist zweigleisig. Für alte Clients an einem rein neuen Server bleibt es beim Fehlschlag.

Abgekündigt, mit Frist

Drei Bestandteile sind als abgekündigt markiert: Roots, Sampling und Logging. Nach der Änderungsliste (externe Seite, modelcontextprotocol.io) funktionieren sie während der Abkündigungsfrist vollständig weiter, neue Umsetzungen sollen sie aber nicht mehr unterstützen. Vorgeschlagen wird jeweils ein gewöhnlicher Ersatz: Verzeichnisse als Tool-Parameter oder Ressourcenadresse statt Roots, die direkte Anbindung an eine Modell-Schnittstelle statt Sampling, Ausgabe nach stderr oder OpenTelemetry statt Logging.

Neu ist dabei weniger die Abkündigung als die Politik dahinter: Die Fassung führt einen Lebenszyklus mit den Zuständen aktiv, abgekündigt und entfernt ein, mit mindestens zwölf Monaten zwischen den letzten beiden. Für ein Protokoll, das Ende 2024 gestartet ist und seither in schneller Folge Fassungen ausgeliefert hat, ist eine verbindliche Frist die eigentliche Nachricht. Sie macht Planung möglich.

Ebenfalls gestrichen, ohne Frist: ping, logging/setLevel und die Meldung über geänderte Roots. Der Protokollstand für Meldungen wird jetzt je Anfrage gesetzt.

Was das praktisch heißt

Wer MCP nur benutzt, merkt davon zunächst wenig. Die Arbeit liegt bei denen, die Server und Clients bauen. Die Bibliotheken für TypeScript, Python, Go und C# sprechen die Fassung seit dem Tag ihrer Freigabe, so die Freigabemeldung (externe Seite, blog.modelcontextprotocol.io) für alle vier Bibliotheken der obersten Stufe. Vorabfassungen gab es seit dem 29. Juni 2026. Bei Python und TypeScript ist das eine neue Hauptversion, also ein Umbau am eigenen Code, den man selbst terminiert. Für Python riet die Ankündigung der Vorabfassungen, in Abhängigkeiten eine Obergrenze zu setzen, etwa mcp>=1.27,<2, damit die neue Hauptversion nicht ungefragt einzieht; wer das getan hat, bleibt bis zum eigenen Umstieg auf dem alten Stand. Für TypeScript liegt ein Werkzeug bei, das den Quelltext umschreibt, und die Reihe 1.x bekommt ab der Freigabe noch mindestens sechs Monate Fehlerbehebungen und Sicher­heits­up­dates (Beleg (externe Seite, blog.modelcontextprotocol.io)).

Die nüchterne Einschätzung für eigene Umgebungen: Lokale Server über stdio sind von der Skalierungsfrage nicht betroffen, wohl aber vom Wegfall des Handshakes. Wer Server im Netz betreibt, gewinnt sofort etwas, sobald mehr als eine Instanz läuft. Und wer Tools gebaut hat, die sich zwischen zwei Aufrufen etwas merken, hat Arbeit vor sich, weil dieses Merken jetzt sichtbar durch die Aufrufe wandern muss.

Was dieser Text nicht sagt

Alle Angaben stammen aus der Spezifikation in der Fassung 2026-07-28 (Änderungsliste, Grundlagen, Transport, Versionierung, Rückfragemuster, Tool-Seite, Architektur) sowie aus drei Ankündigungen der Betreuer vom 21. Mai, 29. Juni und 28. Juli 2026. Die Verweise zeigen auf die feste Fassung 2026-07-28 statt auf den Entwurfspfad: Der wandert mit der nächsten Fassung weiter und belegt deshalb nichts.

Hier steht keine Erfahrung mit der neuen Fassung im Betrieb. Ob das Wie­der­ho­lungs­muster bei Rückfragen in der Praxis angenehm zu programmieren ist, ob Modelle mit durchgereichten Kennungen zuverlässig umgehen, und wie viele Server die Zweigleisigkeit tatsächlich anbieten, ist bisher nicht gemessen.