Stateless MCP-Server: Was hat sich wirklich geändert?

Was ein zustandsloser MCP-Server ist

Ein zustandsloser MCP-Server speichert zwischen Anfragen keinen clientbezogenen Zustand. Jede Anfrage enthält die Protokollversion, die Client-Funktionen und die Zugangsdaten, die der Server für ihre Verarbeitung benötigt. Daher kann jeder Prozess auf jedem Rechner jede Anfrage beantworten. MCP (Model Context Protocol, das Übertragungsformat, mit dem Agents auf Tools zugreifen) hat dies in Revision 2026-07-28 verbindlich festgelegt. Dabei wurden der initialize-Handshake und die darunterliegende HTTP-Sitzung entfernt.

Das ist der gesamte praktische Zweck. Ein Server, der keine clientbezogenen Daten speichert, kann hinter einem gewöhnlichen Load Balancer ohne Sitzungsaffinität betrieben werden. Er kann während eines Deployments neu gestartet werden, ohne dass Clients ihre Verbindung verlieren. Außerdem kann er als vier identische Prozesse statt als einzelner Prozess ausgeführt werden. Ein sitzungsorientierter Server kann dies ohne zusätzliche Komponenten nicht leisten.

Das Model Context Protocol ist ein zustandsloses Protokoll: Alle Informationen, die für die Verarbeitung einer Anfrage erforderlich sind, sind in der Anfrage selbst enthalten. Ein Server verarbeitet jede Anfrage unabhängig. Aus vorherigen Anfragen darf kein Zustand abgeleitet werden, auch nicht aus Anfragen über dieselbe Verbindung oder denselben Datenstrom.

Zustandslos bedeutet nicht, dass Ihr Server nichts speichert. Ihre Datenbank, Ihre Warteschlange und Ihr Cache bleiben bestehen. Es bedeutet, dass das Protokoll keinen Zustand auf der Verbindung überträgt. Der Server darf daher eine Verbindung, einen Prozess oder einen offenen Socket nicht als Ersatz für „dieser Client mitten in einer Unterhaltung“ behandeln.

Was die Revision vom 2026-07-28 entfernt hat

2026-07-28 ist der aktuelle Stand der Spezifikation im August 2026. Im Vergleich zu 2025-11-25 entfernt sie fünf Funktionen, die zur Unterstützung von Sitzungen vorhanden waren.

• Die initialize-Anforderung und die notifications/initialized-Benachrichtigung. Es gibt überhaupt keinen Handshake (SEP-2575).
• Den Mcp-Session-Id-Header und die Beendigung von Sitzungen mit HTTP DELETE (SEP-2567).
• Den eigenständigen HTTP-GET-Stream, über den Server Benachrichtigungen übermittelten. Er wird durch subscriptions/listen ersetzt, einen gewöhnlichen POST, dessen Antwort ein langlebiger Stream ist.
• Die Wiederaufnahmefähigkeit von SSE-Streams (serverseitig gesendete Ereignisse). Der Last-Event-ID-Header und die IDs einzelner Ereignisse entfallen. Wenn ein Stream unterbrochen wird, geht die laufende Anfrage verloren. Der Client muss sie als neue Anfrage mit einer neuen Request-ID erneut senden.
• ping, logging/setLevel und notifications/roots/list_changed. Die Protokollstufe ist jetzt ein Feld pro Anfrage, io.modelcontextprotocol/logLevel in _meta.

Eine Methode wurde hinzugefügt, und jeder Server muss sie implementieren. server/discover gibt die unterstützten Protokollversionen, die Fähigkeiten und die Identität des Servers in einem Aufruf zurück. Sie kommt einem noch vorhandenen Handshake am nächsten. Für Clients ist ihr Aufruf jedoch optional.

Warum der Sitzungstransport im Produktivbetrieb schwer zu betreiben war

In 2025-11-25 und früher konnte ein Server bei der Initialisierung eine Sitzungs-ID erzeugen und sie im Mcp-Session-Id-Header der InitializeResult-Antwort zurückgeben. Der Client musste diesen Header anschließend bei jeder weiteren Anfrage mitsenden. Die ausgehandelte Protokollversion und die Fähigkeiten des Clients wurden im Speicher des Servers abgelegt und über diese ID zugeordnet. Jede dieser Entscheidungen verursachte einen betrieblichen Aufwand.

• Bei einem Neustart wurde die Sitzungstabelle verworfen. Die Spezifikation verlangte, dass der Server auf jede Anfrage mit einer nicht mehr gültigen Sitzungs-ID mit 404 Not Found antwortet. Außerdem musste der Client mit einem neuen InitializeRequest von vorn beginnen. Jeder Deploy wurde dadurch für alle verbundenen Clients zu einem erneuten Verbindungsaufbau.
• Eine zweite Replica kannte die Sitzungen der ersten Replica nicht. Eine horizontale Skalierung erforderte daher entweder Sticky Routing auf dem Load Balancer oder einen gemeinsamen Sitzungsspeicher, aus dem jede Replica bei jeder Anfrage lesen musste.
• Die Sitzungstabelle belegte Speicher, der mit der Zahl der inaktiven Clients wuchs. DELETE war optional. Clients, die die Verbindung schlossen, ohne es zu senden, hinterließen Einträge.
• Die Ergebnisse von Listenoperationen konnten sich je nach Verbindung unterscheiden. Caching vor dem Server war daher nicht sicher.

Durch das Entfernen der Sitzungen entfallen alle vier Probleme gleichzeitig. Diese Änderung sollten Sie verstehen, bevor Sie eine Konfiguration anpassen.

Was jede Anfrage jetzt enthält

Jeder POST an den MCP-Endpunkt steht für sich. Die Protokollversion und die Client-Funktionen werden im Anforderungstext unter _meta übertragen. Ausgewählte Felder werden zusätzlich in HTTP-Header gespiegelt, damit ein Vermittler anhand dieser Felder routen kann, ohne JSON zu parsen.

POST /mcp HTTP/1.1
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_weather
Authorization: Bearer <access token>

{
  "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": {}
    }
  }
}

io.modelcontextprotocol/protocolVersion und io.modelcontextprotocol/clientCapabilities sind bei jeder Anfrage erforderlich. clientInfo ist nicht erforderlich, Clients sollten es jedoch senden. Eine Anfrage ohne ein erforderliches Feld ist fehlerhaft. Der Server muss sie mit dem JSON-RPC-Fehler -32602 und HTTP 400 Bad Request ablehnen.

Der Header Mcp-Method ist bei jeder Anfrage erforderlich. Mcp-Name ist bei tools/call, resources/read und prompts/get erforderlich. Der Header-Wert muss mit dem Anforderungstext übereinstimmen. Ein Server, der den Anforderungstext verarbeitet, muss eine Abweichung mit 400 Bad Request sowie dem Fehlercode -32020, HeaderMismatch ablehnen. Diese Regel ist erforderlich, weil ein Load Balancer, der anhand des Headers routet, und ein Server, der den Anforderungstext ausführt, zwei unterschiedliche Wahrheitsquellen verwenden. Wenn Sie anhand dieser Header routen oder die Rate begrenzen, prüfen Sie zuerst MCP-Protocol-Version. Frühere Revisionen validierten den Header nicht gegen den Anforderungstext. Bei diesen Versionen ist der Header-Wert daher nicht vertrauenswürdig.

Eine abweichende Version ist jetzt ein gewöhnlicher Fehler für eine einzelne Anfrage und kein fehlgeschlagener Handshake mehr. Ein Server, der die angeforderte Version nicht implementiert, antwortet mit 400 Bad Request sowie den Fehlern -32022 und UnsupportedProtocolVersion und listet in data.supported die von ihm unterstützten Versionen auf. Der Client wählt eine Version aus dieser Liste und versucht die Anfrage erneut.

Wohin der Zustand verlagert wurde: Tokens, Cursor, Abonnements

Der Zustand ist nicht verschwunden. Er befindet sich jetzt an Stellen, die Sie einsehen und protokollieren können.

Anmeldedaten werden in jede Anfrage übernommen. Es gibt keine Sitzung, an die eine Identität gebunden werden kann. Daher wird das Zugriffstoken bei jedem HTTP-Aufruf übertragen und jedes Mal validiert. Einzelheiten finden Sie im folgenden Abschnitt zur Authentifizierung.

Cursor müssen ihre eigene Position enthalten. Die Seitennavigation auf tools/list, resources/list, prompts/list und resources/templates/list verwendet eine undurchsichtige Cursor-Zeichenfolge. Clients dürfen sie weder analysieren noch ändern. Auf einem Server mit einem einzigen Prozess war es üblich, den Offset sitzungsbezogen im Speicher abzulegen. Ohne Sitzung muss der Cursor ausreichen, damit jedes Replikat die Auflistung fortsetzen kann. Codieren Sie die Position daher im Cursor und signieren Sie ihn, oder speichern Sie sie in einem Speicher, den alle Replikate gemeinsam nutzen. Ein ungültiger Cursor sollte -32602 zurückgeben. Signieren Sie ihn, weil ein undurchsichtiger Cursor weiterhin eine vom Client gelieferte Eingabe ist, die Ihr Code decodiert und der er vertraut.

Abonnements gehören zu einer Anfrage, nicht zu einer Verbindung. Ein Client, der Änderungsbenachrichtigungen erhalten möchte, sendet subscriptions/listen mit einem Filter, der die gewünschten Typen angibt: toolsListChanged, promptsListChanged, resourcesListChanged und resourceSubscriptions. Der Server antwortet mit notifications/subscriptions/acknowledged und hält diesen Antwortdatenstrom offen. Wenn der Datenstrom abbricht, behält der Server nichts bei. Der Client sendet subscriptions/listen erneut, um ihn wiederherzustellen.

Anwendungszustand über mehrere Aufrufe hinweg wird zu einem expliziten Handle. Wenn ein Server tatsächlich etwas zwischen Aufrufen speichern muss, sieht die Spezifikation dafür eine vom Server erzeugte Kennung vor, die als gewöhnliches Tool-Argument zurückübergeben wird. Sie erscheint im Tool-Schema, kann protokolliert werden und wird niemals implizit aus der Verbindung abgeleitet. Ein Server mit echten benutzerbezogenen Daten im Hintergrund, beispielsweise ein selbst gehosteter MCP-E-Mail-Server, verwendet dieses Muster anstelle einer Sitzung: Die Kennung des Postfachs oder Entwurfs wird als Tool-Argument übergeben, sodass jedes Replikat den nächsten Aufruf übernehmen kann.

Bereitstellung: Reverse Proxy, Timeouts, Health Checks

Der MCP-Endpunkt ist ein Pfad, der POST akzeptiert. Der meiste Datenverkehr besteht aus einer kurzen Anfrage und einer JSON-Antwort, die jeder Proxy verarbeitet. Die Ausnahme ist die Streaming-Antwort. Bei ihr wirken sich die Proxy-Standardeinstellungen nachteilig aus. Dieser Teil ändert sich, wenn Sie von einer Laptop-Demo zu einem MCP-Server auf einem VPS wechseln.

location /mcp {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_buffering off;
    proxy_read_timeout 1h;
    proxy_send_timeout 1h;
}

proxy_buffering off ist wichtig, weil nginx weitergeleitete Antworten standardmäßig puffert. Dadurch hält nginx SSE-Ereignisse zurück, bis ein Puffer gefüllt ist oder die Antwort endet. Die Spezifikation verlangt außerdem, dass Server X-Accel-Buffering: no in SSE-Antworten senden. nginx berücksichtigt diesen Header. Ein korrekter Server teilt dem Proxy daher selbst die richtige Einstellung mit. Setzen Sie die Direktive trotzdem, denn das ist der Teil, den Sie kontrollieren.

proxy_read_timeout ist standardmäßig auf 60 Sekunden gesetzt. Ein subscriptions/listen-Stream, der länger stillsteht, wird von nginx geschlossen, nicht von Ihrem Server. Dadurch zeigen Ihre Logs einen gesunden Prozess, während Ihr Client einen abgebrochenen Stream meldet. Erhöhen Sie den Wert nur für die MCP-Location, nicht für den gesamten Server. Server sollten während ruhiger Phasen außerdem eine SSE-Kommentarzeile senden, also eine Zeile, die mit einem Doppelpunkt beginnt, und damit die Verbindung aktiv halten. So verhindern sie, dass Vermittler den Stream überhaupt wegen eines Timeouts schließen.

Für Caddy sind weniger Einstellungen erforderlich. Caddy puffert standardmäßig teilweise, um die Übertragung effizienter zu machen, und leert den Puffer sofort, wenn die Antwort Content-Type: text/event-stream enthält. Daher funktioniert Streaming ohne zusätzliche Direktiven.

mcp.example.com {
	reverse_proxy 127.0.0.1:8080 {
		health_uri /healthz
		health_interval 10s
	}
}

Beachten Sie, auf welches Ziel dieser Health Check zeigt. Richten Sie keine aktive Prüfung mit GET auf den MCP-Endpunkt. Ein Server, der nur diese Revision implementiert, antwortet auf 405 Method Not Allowed mit GET und auf DELETE. Die Standardmethode für Health Checks in Caddy ist jedoch GET. Der Proxy würde ein vollständig gesundes Backend deshalb als nicht verfügbar markieren. Stellen Sie für den Proxy einen einfachen Pfad wie /healthz bereit und prüfen Sie das Protokoll separat mit POST.

curl -sS https://mcp.example.com/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2026-07-28' \
  -H 'Mcp-Method: server/discover' \
  -d '{"jsonrpc":"2.0","id":"health-1","method":"server/discover","params":{"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28","io.modelcontextprotocol/clientCapabilities":{}}}}'

Ein 200 mit einer supportedVersions-Liste bedeutet, dass der Prozess läuft und das Protokoll verarbeitet. Ein 404 mit dem JSON-RPC-Fehler -32601 bedeutet, dass der Prozess läuft, aber server/discover nicht bereitstellt. Jeder 2026-07-28-Server muss diese Methode implementieren. Ein 400 mit -32022 bedeutet, dass Ihr Prüfer eine Version angefordert hat, die dieser Build nicht unterstützt. Genau das sollten Sie nach einem Upgrade einer Abhängigkeit erkennen. Open-Source-nginx bietet keine aktiven Health Checks. Verwenden Sie deshalb passive max_fails und fail_timeout für das Upstream und führen Sie die Protokollprüfung stattdessen über Ihr Monitoring aus.

Ein Rolling Restart kostet Sie jetzt nur die laufenden Anfragen. Leeren Sie das Upstream, lassen Sie offene POST-Anfragen abschließen, starten Sie den neuen Prozess und lassen Sie die Clients fehlgeschlagene Anfragen erneut senden. Die eine Verbindung, die Sie weiterhin verlieren, ist jeder offene subscriptions/listen-Stream, weil dieser Stream eine aktive Verbindung zu genau einem Prozess ist. Zustandslosigkeit macht keine Sitzungsaffinität erforderlich. Sie beseitigt jedoch nicht die Verbindungsaffinität für einen Stream, der gerade geöffnet ist. Keine Routing-Regel kann das ändern. Ein Client kann die beiden Fälle unterscheiden: Endet ein Stream mit dem leeren Ergebnis subscriptions/listen, wurde er ordnungsgemäß geschlossen. Endet er ohne dieses Ergebnis, wurde er abgebrochen. Der Client kann das als Grund für eine erneute Verbindung behandeln.

Caching wird erstmals möglich. Ergebnisse der Listenmethoden enthalten nun ttlMs und cacheScope. cacheScope: "public" teilt gemeinsam genutzten Vermittlern mit, dass sie die Antwort im Cache speichern dürfen. Das ist nur sicher, weil die Listenergebnisse nicht mehr von der Verbindung abhängen. Das ist eine direkte Folge des Entfernens von Sitzungen.

Warum sich die Authentifizierung ohne Session ändert

Mit einer Session lag es nahe, sich einmal bei initialize zu authentifizieren und die Session-ID anschließend als Nachweis für alle weiteren Vorgänge zu verwenden. Eine auf diese Weise verwendete Session-ID ist ein Bearer-Credential ohne Zielgruppe, Ablaufzeit und Möglichkeit zum Widerruf, das vom eigenen Server ausgestellt wurde. Wenn Sessions entfernt werden, entfällt diese Abkürzung. Der Ersatz ist strenger.

Ein geschützter MCP-Server fungiert als OAuth-2.1-Resource-Server. Jede HTTP-Anfrage des Clients muss Authorization: Bearer <access token> enthalten. Der Server validiert das Token bei jeder Anfrage. Zur Validierung gehört auch die Zielgruppe: Der Server muss gemäß RFC 8707 (Resource Indicators for OAuth 2.0) bestätigen, dass das Token spezifisch für ihn ausgestellt wurde. Tokens, die für andere Ziele bestimmt sind, darf er weder akzeptieren noch weiterleiten. Clients fordern die richtige Zielgruppe an, indem sie den Parameter resource mit der kanonischen URI des Servers senden.

Die Ermittlung der Konfiguration beginnt mit einer Challenge. Wenn eine Anfrage ohne nutzbares Token eintrifft, antwortet der Server mit 401 Unauthorized.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         scope="files:read"

Der Client liest resource_metadata, ruft dieses Dokument ab (RFC 9728, OAuth 2.0 Protected Resource Metadata, das MCP-Server implementieren müssen), ermittelt den Authorization-Server und führt den Ablauf aus. Ein gültiges Token mit zu wenigen Berechtigungen führt zu 403 Forbidden mit error="insufficient_scope" und den für diesen Vorgang erforderlichen Scopes.

Das hat zwei Folgen für den Betrieb. Die Token-Validierung erfolgt jetzt bei jeder Anfrage statt einmal pro Session. Ein Netzwerk-Roundtrip zu einem Introspection-Endpunkt pro Aufruf wirkt sich daher auf die Latenz aus. Bevorzugen Sie Tokens, die Sie lokal anhand einer Signatur, einer Zielgruppe und einer Ablaufzeit prüfen können. Alternativ können Sie das Validierungsergebnis für ein kurzes Zeitfenster zwischenspeichern, wobei das Token als Schlüssel dient. Da keine Session mehr eine Identität hält, muss die Autorisierung bei jedem Aufruf aus dem Token ermittelt werden. Das ist transparenter als das Session-Modell und entspricht der allgemeinen Praxis, Zugangsdaten aus dem Agent-Prozess herauszuhalten. Diese Praxis wird in Zugangsdaten aus einem AI-Agenten heraushalten behandelt.

Was für diese Revision gilt und was nicht

Alles oben beschreibt die Revision 2026-07-28. Es beschreibt MCP nicht dauerhaft und auch nicht den Server, den Sie im vergangenen Jahr bereitgestellt haben.

Clients und Server mit 2025-11-25 und älteren Revisionen verwenden weiterhin das Handshake-Modell. Die Spezifikation bezeichnet diese Revisionen als veraltet und die Revisionen mit Metadaten pro Anfrage als modern. Ein Server, der nur diese Revision unterstützt und auf einen älteren Client trifft, sollte am MCP-Endpunkt auf GET oder DELETE mit 405 Method Not Allowed antworten, jeden Mcp-Session-Id-Header ohne Erzeugung oder Zurückgeben eines solchen Headers ignorieren und Last-Event-ID ignorieren, weil Streams nicht fortgesetzt werden können. Ein Server, der beide Entwicklungszeiträume unterstützt, kann beide Modelle an einem Endpunkt anbieten: Eine Anfrage mit modernem _meta wird zustandslos verarbeitet, und eine initialize-Anfrage wählt die älteren Sitzungssemantiken.

Prüfen Sie daher die Revisionszeichenfolge, bevor Sie diese Aussagen übernehmen. Wenn Ihr SDK weiterhin initialize sendet, sind Sitzungen für Ihre Bereitstellung weiterhin relevant, und Sie müssen die oben beschriebenen sitzungsbezogenen Probleme weiterhin verwalten. Dasselbe gilt auf der Clientseite: Ein Agent-Prozess auf Ihrem eigenen System, beispielsweise die Einrichtung unter einen Coding-Agent auf einem VPS ausführen, ist in diesem Sinn nur dann zustandslos, wenn die verwendete Bibliothek eine moderne Revision spricht. Lesen Sie die Version, die Ihre Laufzeitumgebung aushandelt, und anschließend die zugehörige Revision der Spezifikation. Betrachten Sie diese Seite als Beschreibung einer bestimmten Revision und nicht des Protokolls im Allgemeinen.

FAQ

Bedeutet ein zustandsloser MCP-Server, dass ich nichts speichern kann?

Nein. Zustandslosigkeit beschreibt das Protokoll, nicht Ihre Anwendung. Datenbanken, Warteschlangen und Caches funktionieren weiterhin wie bisher. Ändert sich, dass sich ein Zustand über mehrere Aufrufe erstreckt, muss dieser über einen expliziten Bezeichner referenziert werden, den der Client bei jeder Anfrage übergibt, beispielsweise über ein vom Server erzeugtes Handle in einem Tool-Argument. Sie dürfen keinen Kontext aus der Verbindung ableiten: Die Spezifikation schreibt vor, dass sich ein Server nicht auf vorherige Anfragen über dieselbe Verbindung stützen darf, um Fähigkeiten, Protokollversion oder Client-Identität festzustellen, weil jede Anfrage diese Informationen in _meta übermittelt.

Benötige ich weiterhin Sticky Sessions auf meinem Load Balancer?

Für gewöhnliche Anfragen nicht. Unter Revision 2026-07-28 enthält jeder POST seine eigene Protokollversion, seine Fähigkeiten und seine Anmeldedaten. Daher kann jede Replik jede Anfrage beantworten, und Round-Robin ist ausreichend. Das einzige verbleibende langlebige Element ist der subscriptions/listen-Antwortstream. Dabei handelt es sich um eine einzelne offene Verbindung zu einem einzelnen Prozess. Sie endet, wenn dieser Prozess endet, und der Client sendet subscriptions/listen erneut, um sie wiederherzustellen. Das betrifft die Lebensdauer der Verbindung und nicht die Sitzungsaffinität. Keine Routing-Regel verhindert dies.

Was ist mit Mcp-Session-Id und dem HTTP-GET-Stream passiert?

Beide wurden in Revision 2026-07-28 unter SEP-2567 und SEP-2575 entfernt. Ein Server, der nur diese Revision implementiert, sollte auf GET und DELETE am MCP-Endpunkt mit 405 Method Not Allowed antworten und einen Mcp-Session-Id-Header ignorieren, statt ihn zurückzusenden. Vom Server initiierte Änderungsbenachrichtigungen werden jetzt im Antwortstream einer subscriptions/listen-Anfrage übertragen und nicht mehr über einen eigenständigen GET-Stream. Server, die weiterhin ältere Clients bedienen müssen, implementieren das Verhalten der früheren Revision zusätzlich zu diesem Verhalten.

Wie führe ich einen Health Check für einen MCP-Server ohne Handshake durch?

Verwenden Sie zwei Ebenen. Richten Sie die aktive Prüfung des Proxys auf einen einfachen HTTP-Pfad, den Ihre Anwendung bereitstellt. Ein GET an den MCP-Endpunkt liefert korrekt 405 und würde ein funktionsfähiges Backend als nicht verfügbar markieren. Prüfen Sie anschließend das Protokoll selbst, indem Sie server/discover per POST senden. Jeder 2026-07-28-Server muss dies implementieren. Stellen Sie sicher, dass die Antwort HTTP 200 lautet und eine Protokollversion auflistet, die Ihre Clients verwenden. Ein 404 mit dem JSON-RPC-Fehler -32601 bedeutet, dass der Prozess läuft, diese Methode aber nicht bereitstellt. Ein 400 mit -32022 bedeutet, dass die angeforderte Version von diesem Build nicht unterstützt wird.