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

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 Anmeldedaten, 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, über das Agents Tools erreichen) hat dies in Revision 2026-07-28 als Regel festgelegt. Dabei wurden der initialize-Handshake und die darunterliegende HTTP-Sitzung entfernt. In diesem Abschnitt geht es ausschließlich um die Serverseite dieses Übertragungsformats. Wenn die Agentenseite für Sie noch neu ist, beschreibt ein schrittweiser Lernpfad für AI-Agents die Schleife, die vor jeder weiteren Betrachtung der HTTP-Details über den Aufruf eines Tools entscheidet.

Das ist der gesamte operative Zweck. Ein Server, der keinen clientbezogenen Zustand speichert, kann hinter einem gewöhnlichen Load Balancer ohne Session-Affinität betrieben werden. Er kann während eines Deployments neu gestartet werden, ohne dass die Clients dadurch beeinträchtigt werden. Außerdem kann er als vier identische Prozesse statt als einzelner Prozess ausgeführt werden. Ein sitzungsorientierter Server kann dies ohne zusätzliche Infrastruktur 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 dann nicht, wenn sie über dieselbe Verbindung oder denselben Stream übertragen wurden.

Stateless bedeutet nicht, dass Ihr Server nichts speichert. Ihre Datenbank, Ihre Warteschlange und Ihr Cache sind weiterhin vorhanden. Es bedeutet, dass das Protokoll auf der Verbindung keinen Zustand mitführt. Der Server darf daher eine Verbindung, einen Prozess oder einen geöffneten Socket nicht als Ersatz für „dieser Client mitten in einem Dialog“ behandeln. Die Trennung ist bei einer Anwendung, die ihre Daten bereits selbst verwaltet, besonders einfach zu erkennen: der schreibgeschützte MCP-Server von openGym beantwortet Fragen zur Trainingshistorie, die in der eigenen Datenbank der Anwendung gespeichert ist. Nichts an dieser Speicherung hängt von der Verbindung ab, über die eine bestimmte Anfrage eingegangen ist.

Entfernte Inhalte in Revision 2026-07-28

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

• Die initialize-Anfrage und die notifications/initialized-Benachrichtigung. Es gibt überhaupt keinen Handshake (SEP-2575).
• Den Header Mcp-Session-Id und die Sitzungsbeendigung 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 Möglichkeit, SSE-Streams (serverseitige Ereignisse) fortzusetzen. Der Header Last-Event-ID und die IDs der einzelnen Ereignisse entfallen. Wenn ein Stream abbricht, geht die laufende Anfrage verloren. Der Client muss sie als neue Anfrage mit einer neuen Anfrage-ID erneut senden.
• ping, logging/setLevel und notifications/roots/list_changed. Die Protokollebene ist jetzt ein Anfragefeld, io.modelcontextprotocol/logLevel in _meta.

Eine Methode wurde hinzugefügt, und jeder Server muss sie implementieren. server/discover liefert in einem Aufruf die unterstützten Protokollversionen, Funktionen und die Identität des Servers zurück. Sie kommt einem verbleibenden 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 Header Mcp-Session-Id der InitializeResult-Antwort zurückgeben. Der Client musste diesen Header anschließend mit jeder weiteren Anfrage senden. Die ausgehandelte Protokollversion und die Fähigkeiten des Clients lagen im Speicher des Servers und waren über diese ID zugeordnet. Jede dieser Entscheidungen verursachte zusätzlichen Betriebsaufwand.

• Ein Neustart verwarf die Sitzungstabelle. Die Spezifikation verlangte, dass der Server auf jede Anfrage mit einer ungültigen Sitzungs-ID mit 404 Not Found antwortet. Außerdem musste der Client mit einem neuen InitializeRequest von vorn beginnen. Jede Bereitstellung führte daher für jeden verbundenen Client zu einer erneuten Verbindung.
• Eine zweite Replik kannte die Sitzungen der ersten Replik nicht. Eine horizontale Skalierung erforderte entweder Sticky Routing am Load Balancer oder einen gemeinsam genutzten Sitzungsspeicher, den jede Replik bei jeder Anfrage lesen musste.
• Die Sitzungstabelle belegte Speicher, der mit der Anzahl inaktiver Clients wuchs. DELETE war optional. Clients, die die Verbindung schlossen, ohne es zu senden, hinterließen Einträge.
• Die Ergebnisse von Listenabfragen konnten je Verbindung variieren. Ein vorgeschalteter Cache war daher unsicher.

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

Was jede Anfrage jetzt überträgt

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 zwischengeschaltetes System anhand dieser Felder routen kann, ohne JSON zu analysieren.

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 für jede Anfrage erforderlich. clientInfo ist nicht erforderlich, Clients sollten es jedoch mitsenden. Eine Anfrage, bei der ein erforderliches Feld fehlt, ist fehlerhaft. Der Server muss sie mit dem JSON-RPC-Fehler -32602 und HTTP 400 Bad Request ablehnen.

Der Header Mcp-Method ist für jede Anfrage erforderlich. Mcp-Name ist für tools/call, resources/read und prompts/get erforderlich. Der Headerwert muss mit dem Anforderungstext übereinstimmen. Ein Server, der den Anforderungstext verarbeitet, muss eine Abweichung mit 400 Bad Request und 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 Datenquellen 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 Headerwert daher nicht vertrauenswürdig.

Eine abweichende Version führt jetzt zu einem normalen Fehler für die einzelne Anfrage und nicht mehr zu einem fehlgeschlagenen Handshake. Ein Server, der die angeforderte Version nicht implementiert, antwortet mit 400 Bad Request und dem Fehler -32022, UnsupportedProtocolVersion. Außerdem listet er unter data.supported die unterstützten Versionen auf. Der Client wählt eine Version aus dieser Liste und sendet die Anfrage erneut.

Wohin der Zustand verschoben wurde: Tokens, Cursor und Abonnements

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

Anmeldedaten werden Bestandteil jeder Anfrage. Es gibt keine Sitzung, an die eine Identität gebunden werden kann. Daher wird das Zugriffstoken bei jedem HTTP-Aufruf mitgesendet und jedes Mal geprüft. Weitere Informationen finden Sie im folgenden Abschnitt zur Authentifizierung.

Cursor müssen ihre eigene Position enthalten. Die Paginierung für tools/list, resources/list, prompts/list und resources/templates/list verwendet eine undurchsichtige Cursor-Zeichenfolge. Clients dürfen sie weder parsen noch ändern. Auf einem Server mit nur einem Prozess war es üblich, den Offset im Speicher zu halten und ihn der Sitzung zuzuordnen. 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 verwenden. 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 Antwortstream offen. Wenn der Stream abbricht, behält der Server nichts zurück. Der Client sendet subscriptions/listen erneut, um ihn wiederherzustellen.

Anwendungszustand über mehrere Aufrufe hinweg wird zu einem expliziten Handle. Wenn sich ein Server tatsächlich etwas zwischen Aufrufen merken muss, sieht die Spezifikation dafür eine vom Server erzeugte Kennung vor, die als gewöhnliches Tool-Argument zurückgegeben wird. Sie erscheint im Tool-Schema, kann protokolliert werden und wird niemals implizit aus der Verbindung abgeleitet. Ein Server mit echten benutzerbezogenen Daten dahinter, beispielsweise ein selbst gehosteter MCP-E-Mail-Server, verwendet dieses Muster anstelle einer Sitzung. Die Kennung des Postfachs oder Entwurfs ist ein Tool-Argument, sodass jedes Replikat den nächsten Aufruf übernehmen kann. Viele Tools benötigen überhaupt kein Handle: ein Suchtool mit einer eigenen SearXNG-Instanz im Hintergrund nimmt eine Suchanfrage entgegen und gibt Ergebnisse zurück. Für den nächsten Aufruf gibt es nichts fortzusetzen, und es spielt keine Rolle, welches Replikat geantwortet hat.

Deployment: Reverse-Proxy, Timeouts und Health Checks

Der MCP-Endpunkt ist ein Pfad, der POST akzeptiert. Der meiste Datenverkehr besteht aus einer kurzen Anfrage und einer JSON-Antwort, mit der jeder Proxy umgehen kann. Die Ausnahme ist die Streaming-Antwort, bei der sich die Standardwerte des Proxys nachteilig auswirken. 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 Ihrem Proxy daher selbst die richtige Einstellung mit. Setzen Sie die Direktive trotzdem, weil dies der Teil ist, den Sie kontrollieren.

proxy_read_timeout ist standardmäßig auf 60 Sekunden gesetzt. Ein subscriptions/listen-Stream, der länger als diese Zeit inaktiv bleibt, wird von nginx und nicht von Ihrem Server geschlossen. Ihre Logs zeigen dann einen fehlerfreien Prozess, während Ihr Client einen abgebrochenen Stream meldet. Erhöhen Sie den Wert nur für den MCP-Abschnitt und nicht für den gesamten Server. Server sollten während längerer Ruhephasen außerdem eine SSE-Kommentarzeile senden, also eine Zeile, die mit einem Doppelpunkt beginnt. Dadurch wird verhindert, dass zwischengeschaltete Komponenten den Stream überhaupt wegen eines Timeouts schließen.

Caddy benötigt weniger Konfiguration. Es 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. Das Streaming funktioniert daher ohne zusätzliche Direktiven.

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

Beachten Sie, worauf dieser Health Check zugreift. Richten Sie keinen aktiven Check mit GET auf den MCP-Endpunkt. Ein Server, der nur diese Revision implementiert, antwortet auf 405 Method Not Allowed mit GET und DELETE. Caddys Standardmethode für Health Checks ist GET. Der Proxy würde ein vollständig funktionsfähiges Backend daher 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 einem 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 spricht. 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 Check 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 daher passive max_fails und fail_timeout für das Upstream und führen Sie den Protokoll-Check stattdessen aus Ihrem Monitoring aus.

Ein Rolling Restart kostet Sie jetzt nur die Requests, die gerade verarbeitet werden. Leiten Sie den Datenverkehr aus, 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 weiterhin abbricht, ist jeder offene subscriptions/listen-Stream, weil dieser Stream eine aktive Verbindung zu genau einem Prozess ist. Zustandslosigkeit beseitigt die Sitzungsaffinität. Sie beseitigt jedoch nicht die Verbindungsaffinität eines aktuell offenen Streams. Keine Routing-Regel kann das ändern. Ein Client kann unterscheiden: Ein Stream, der mit dem leeren Ergebnis subscriptions/listen endet, wurde ordnungsgemäß geschlossen. Ein Stream, der ohne dieses Ergebnis endet, wurde abgebrochen. Der Client kann dies als Grund für eine erneute Verbindung behandeln.

Caching wird erstmals möglich. Ergebnisse der List-Methoden enthalten jetzt ttlMs und cacheScope. cacheScope: "public" teilt gemeinsam genutzten Zwischenkomponenten mit, dass sie die Antwort cachen dürfen. Das ist nur deshalb sicher, weil sich die Ergebnisse der List-Methoden nicht mehr pro Verbindung unterscheiden. Dies ist eine direkte Folge der entfernten 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 von Ihrem eigenen Server ausgestellt wird. 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. Dazu gehört auch die Zielgruppe: Der Server muss gemäß RFC 8707 (Resource Indicators for OAuth 2.0) bestätigen, dass das Token ausdrücklich 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 Discovery wird durch eine Challenge ausgelöst. Wenn eine Anfrage ohne verwendbares Token eingeht, 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 das 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 einen kurzen Zeitraum zwischenspeichern und dabei das Token als Schlüssel verwenden. Da keine Session eine Identität hält, muss die Autorisierung bei jedem Aufruf aus dem Token berechnet werden. Das ist transparenter als das Session-Modell und passt zur allgemeinen Praxis, Credentials aus dem Agent-Prozess herauszuhalten. Diese Praxis wird unter Secrets aus einem AI-Agenten heraushalten beschrieben. Scopes beschränken nur, was ein Token tun darf, sobald die Anfrage Ihren Server erreicht. Auf dem Rechner, auf dem der Agent ausgeführt wird, legen Harness-Plugins, die Berechtigungsregeln für Tools und Budgetlimits hinzufügen fest, welche Aufrufe überhaupt erfolgen.

Was für diese Revision gilt und was nicht

Alles oben Beschriebene bezieht sich auf Revision 2026-07-28. Es beschreibt MCP nicht dauerhaft und auch nicht den Server, den Sie im letzten Jahr bereitgestellt haben.

Clients und Server mit 2025-11-25 und älteren Revisionen verwenden weiterhin das Handshake-Modell. Die Spezifikation bezeichnet diese Revisionen als Legacy-Revisionen und die Revisionen mit Metadaten pro Anfrage als moderne Revisionen. Ein Server, der ausschließlich 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 ignorieren, ohne einen solchen zu erzeugen oder zurückzusenden, und Last-Event-ID ignorieren, weil Streams nicht fortgesetzt werden können. Ein Server, der beide Epochen unterstützt, kann beide Modelle an einem Endpunkt bereitstellen: Eine Anfrage mit modernem _meta wird zustandslos verarbeitet, während eine Anfrage mit initialize die älteren Sitzungssemantiken auswählt.

Prüfen Sie daher die Revisionszeichenfolge, bevor Sie diese Aussagen übernehmen. Wenn Ihr SDK weiterhin initialize sendet, sind Sitzungen in Ihrer Bereitstellung weiterhin relevant, und die oben beschriebenen sitzungsbezogenen Probleme müssen weiterhin von Ihnen verwaltet werden. Dasselbe gilt auf der Clientseite: Ein Agent-Prozess auf Ihrem eigenen System, beispielsweise bei der Einrichtung unter Ausführen eines Coding-Agenten auf einem VPS, ist in diesem Sinn nur dann zustandslos, wenn die verwendete Bibliothek eine moderne Revision unterstützt. Lesen Sie die Version, die Ihre Laufzeitumgebung aushandelt. Lesen Sie anschließend die entsprechende Revision der Spezifikation. Betrachten Sie diese Seite als Beschreibung einer benannten 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 zuvor. Wenn sich ein Zustand über mehrere Aufrufe erstreckt, muss er durch eine explizite Kennung referenziert werden, die der Client bei jeder Anfrage übergibt, beispielsweise durch ein vom Server erzeugtes Handle in einem Tool-Argument. Sie dürfen den Kontext jedoch nicht aus der Verbindung ableiten: Die Spezifikation schreibt vor, dass ein Server sich nicht auf frühere Anfragen über dieselbe Verbindung stützen darf, um Capabilities, die Protokollversion oder die Clientidentität festzulegen, da jede Anfrage diese Informationen in _meta enthält.

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

Für gewöhnliche Anfragen nicht. In Revision 2026-07-28 enthält jeder POST seine eigene Protokollversion, seine Capabilities und seine Zugangsdaten. 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 geschehen?

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 nun im Antwortstream einer subscriptions/listen-Anfrage übertragen und nicht mehr in einem 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 prüfe ich den Zustand eines MCP-Servers ohne Handshake?

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 gesundes Backend als ausgefallen 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 dabei sicher, dass die Antwort HTTP 200 lautet und eine Protokollversion enthält, die Ihre Clients verwenden. Ein 404 mit dem JSON-RPC-Fehler -32601 bedeutet, dass der Prozess läuft, diese Methode jedoch nicht bereitstellt. Ein 400 mit -32022 bedeutet, dass die angeforderte Version von diesem Build nicht unterstützt wird.