MCP wird stateless — was das für Ihr Gateway bedeutet

16.08.2026

Axel Dunkel

MCP ist jetzt stateless — im Protokollkern. Am 28. Juli 2026 hat das Model Context Protocol die Spezifikation 2026-07-28 veröffentlicht — die Revision, die ihre Maintainer als die wichtigste seit dem Start von Remote MCP bezeichnen, und den Beginn eines Countdowns. Wenn Sie MCP-Server betreiben, sind drei Fähigkeiten, auf die sich Ihr Setup womöglich stillschweigend verlässt — Sampling, Roots und Protokoll-Logging —, jetzt abgekündigt („deprecated”); die Entfernung ist nach zwölf Monaten möglich. Protokoll-Sessions sind ganz verschwunden: Jeder Request steht jetzt für sich.

Dieser Beitrag beantwortet drei Betreiberfragen: was sich tatsächlich geändert hat, was Sie im eigenen MCP-Bestand prüfen sollten, solange die Uhr läuft, und warum die neue Spec — genau gelesen — davon ausgeht, dass zwischen Ihren Agenten und Ihren Servern ein Gateway steht. Das Spec-Detail, jeder Breaking Change mit seiner SEP-Referenz, wartet in der Referenztabelle am Ende des Beitrags.

Was sich geändert hat, in Alltagssprache

Der Release-Post erklärt den Druck hinter der Revision: Die Maintainer berichten von knapp einer halben Milliarde SDK-Downloads pro Monat über die Tier-1-SDKs. In dieser Größenordnung erbt ein Protokoll Infrastrukturprobleme — und MCPs größtes war die Session. Ein Client war an die Server-Instanz gepinnt, die seine Session hielt: Load Balancer brauchten Sticky Sessions, Deployments mussten sie drainen, Serverless-Plattformen kämpften bei jedem Schritt gegen das Protokoll.

Das Changelog zu 2026-07-28 antwortet mit vier Zügen:

Sessions und der initialize-Handshake sind weg. Version, Identität und Capabilities reisen in jedem Request mit — jeder Request kann auf jeder Instanz hinter einem schlichten Round-Robin-Load-Balancer landen.
Zwei Routing-Header werden Pflicht. Jeder Streamable-HTTP-Request trägt Mcp-Method (was aufgerufen wird); Tool-Calls zusätzlich Mcp-Name (welches Tool). Der Zweck: Infrastruktur zwischen Client und Server kann MCP-Traffic routen, drosseln und messen, ohne den JSON-Body zu öffnen.
Server initiieren keine eigenen JSON-RPC-Requests an den Client mehr. Das alte server-initiierte Muster hinter Sampling, Elicitation und Roots wird durch Multi Round-Trip Requests (MRTR) ersetzt: Der Server antwortet „mir fehlt Input” (input_required), und der Client wiederholt den Request mit der Antwort im Gepäck. Notifications gibt es weiterhin — request-bezogene laufen auf dem Response-Stream, und ein langlebiger subscriptions/listen-Stream liefert die Change-Notifications, die ein Client abonniert hat. Eine Fehldeutung gleich vorweg: Elicitation ist nicht deprecated — nur die server-initiierte Form ist weg; Elicitation selbst lebt im MRTR-Muster weiter.
Deprecation wird Policy statt Gewohnheit. Roots, Sampling und Logging funktionieren noch mindestens zwölf Monate, aber Neuimplementierungen sollten sie nicht mehr einsetzen. Der neue Feature-Lifecycle garantiert die Frist; verkürzen kann sie nur ein aktiv ausgenutztes Sicherheitsrisiko — und selbst dann nie unter neunzig Tage.

Die Sessions sind weg — wohin ist der Zustand?

Stateless ist eine Aussage über das Protokoll, nicht über Ihre Anwendung. Das Changelog sagt, wohin Zustand über Calls hinweg jetzt gehört: Server, die ihn brauchen, nutzen „explicit, server-minted handles passed as ordinary tool arguments” (SEP-2567). Ihr Datenbank-Cursor, Ihre SSH-Session, Ihr halb fertiger Workflow — nichts davon ist verschwunden. Es ist eine Schicht nach oben gewandert, aus dem Transport in die Anwendung. Dort muss jetzt etwas diese Handles prägen, ihren Inhalt speichern, sie ablaufen lassen und entscheiden, wer sie benutzen darf.

Merken Sie sich den Gedanken. Zuerst der praktische Teil.

Welche Ihrer MCP-Server nutzen deprecated Capabilities?

Die Zwölf-Monats-Uhr läuft seit dem 28. Juli. Ob Sie drei MCP-Server betreiben oder dreißig: Die Transition ist ein Audit, bevor sie eine Migration ist:

Transporte. Welche Server sprechen noch den HTTP+SSE-Transport von 2024-11-05? Er ist formal deprecated; Ziel ist Streamable HTTP.
Sampling. Welche Server rufen sampling/createMessage auf? Die dokumentierte Migration ist die direkte Integration einer LLM-Provider-API — eine echte Architekturentscheidung (wessen Key, wessen Budget, wessen Logs), kein Suchen-und-Ersetzen.
Roots. Welche Server erwarten roots/list? Migration: Verzeichnisse und Dateien als Tool-Parameter, Resource-URIs oder Server-Konfiguration übergeben.
Logging. Welche Server hängen an logging/setLevel und notifications/message? Beachten Sie: logging/setLevel ist in 2026-07-28 bereits ganz entfernt — der Log-Level wandert als _meta-Feld in den einzelnen Request. Migration: stderr bei stdio, oder OpenTelemetry.
Sessions. Was bricht, wenn Mcp-Session-Id verschwindet? Sticky-Session-Regeln im Load Balancer, jedes Tool, das impliziten Per-Connection-Zustand voraussetzt — und abgerissene SSE-Streams, die nicht mehr per Last-Event-ID wieder aufgenommen, sondern schlicht neu angefragt werden. Redesign auf explizite Handles.
Auth. Dynamic Client Registration ist zugunsten von Client ID Metadata Documents (CIMD) deprecated; Clients müssen einen vorhandenen iss-Parameter validieren (RFC 9207).
SDKs. Die Tier-1-SDKs (TypeScript, Python, Go, C#) sprechen 2026-07-28 bereits; sie müssen deprecated API-Flächen markieren und sollen bei deren Nutzung zur Laufzeit warnen. Behandeln Sie diese Warnungen als Inventurdaten, nicht als Rauschen.

Das praktische Problem: „Welche Server?” zu beantworten heißt, Capability-Nutzung über den gesamten Bestand zu beobachten. Server für Server ist das mühsam — an einem Chokepoint ist es natürlich. Ein Gateway terminiert jede Client-Verbindung und ist damit der eine Ort, an dem Deprecated-Capability-Nutzung als Daten sichtbar wird, pro Backend und pro Client — und an dem während der Frist eine Brücke zwischen Spec-Versionen leben kann. Das breitere Sichtbarkeits-Argument steht in Why MCP Gateways Alone Don’t Solve the Real Problem: Das Gateway ist der Ort, an dem Sie sehen; was Sie dort durchsetzen, ist eine eigene Designentscheidung.

Warum die stateless Spec ein Gateway unterstellt

Vorweg zur Klarheit: Die Spec erfordert kein Gateway — ein Client kann weiterhin direkt mit einem MCP-Server sprechen. Aber wer die Streamable-HTTP-Transport-Spec mit Infrastruktur-Augen liest, sieht ein Muster: Das Protokoll ist erkennbar so gebaut, dass eine Zwischenschicht maximal wirksam wird. Die Spec sagt unumwunden, dass Request-Felder in HTTP-Header gespiegelt werden, damit „intermediaries (load balancers, gateways, observability tooling)” auf Requests reagieren können, ohne den Body zu parsen. Ein stateless Request sieht so aus:

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

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_device",
    "arguments": { "name": "sw-core-01" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {},
      "io.modelcontextprotocol/clientInfo": { "name": "example-client", "version": "1.0.0" }
    }
  }
}

Drei Details zeigen, wie ernst die Spec diese mittlere Schicht nimmt:

Header-Integrität wird erzwungen. Server müssen Requests ablehnen, deren Header dem Body widersprechen (HTTP 400, Fehler HeaderMismatch) — denn ein Load Balancer, der auf einen Header routet, während der Server einen anderen Body ausführt, wäre ein Sicherheitsloch. Man härtet einen solchen Mechanismus nur, wenn man erwartet, dass Komponenten in der Mitte darauf reagieren.
Parameter-Routing steht im Protokoll. Ein Tool-Schema kann Parameter für die Header-Spiegelung markieren (x-mcp-header → Mcp-Param-*) — Tenant-, Regions- oder Projekt-Routing kann so an der Edge passieren, ohne Body-Inspektion.
Geteilte Caches sind erste Klasse. Tool-Listen deklarieren jetzt, wie lange sie gecacht werden dürfen (ttlMs) und von wem (cacheScope); der Wert "public" existiert genau dafür, geteilte Caches zu erlauben, und deterministische Tool-Reihenfolge wird empfohlen, damit Katalog-Caches stabil bleiben. (Die Katalog-Größe ist ein eigenes Problem; dazu Tool Discovery for 4,800 MCP Tools.)

Setzt man die Hälften zusammen: Remote-MCP-Traffic verhält sich jetzt deutlich mehr wie gewöhnlicher HTTP-Traffic — Ihre Infrastruktur kann ihn routen, drosseln, messen und cachen. Anwendungszustand über Calls hinweg wird explizit: Ein Server prägt Handles und verwaltet deren Lifecycle. Und Credentials, Token-Exchange, Policies und Audit bleiben so oder so Betreiberaufgaben. In größeren MCP-Landschaften bündeln sich diese Verantwortlichkeiten natürlich an einem Ort: einer Control Plane auf Anwendungsebene zwischen Agenten und Servern.

Das ist nicht nur unsere Lesart. AWS hat AgentCore-Gateway-Support für 2026-07-28 am Release-Tag ausgeliefert, inklusive Version-Bridging pro Request, damit alte und neue Clients koexistieren. Ein Enterprise-Deployment-Paper auf arXiv (11. August 2026) beschreibt das Governance-Problem Dutzender unabhängig authentifizierender MCP-Server — und löst es mit exakt dieser Komponente: einem Gateway vor allen Downstream-Servern. Und InfoQs Bericht (12. August 2026) hält fest, dass die neuen Header Gateways dieselben Primitiven in die Hand geben, die sie längst auf jede andere API anwenden.

Die Skeptiker sehen dieselben Fakten und drehen sie um. InfoQs Überschrift fragt, ob stateless MCP „just an API again” sei; der Hacker-News-Thread liefert schärfere Varianten: Die Revision ist in beide Richtungen wire-inkompatibel, der Verlust impliziten Session-Zustands ist für Tools, die darauf bauten, eine echte Regression, und datumsbasierte Spec-Versionen machen den Wandel schwer nachverfolgbar. Faire Einwände. Aber man beachte, was sie einräumen: Wenn die Protokollschicht jetzt gewöhnliches HTTP ist, dann entscheidet sich alles, was an Ihrem Deployment noch MCP-spezifisch ist — welche Agenten welche Tools aufrufen dürfen, mit wessen Credentials, unter welchen Policies, mit welchem Audit-Trail —, in dem, was Sie in die Mitte stellen. Die Spec hat diese Schicht nicht überflüssig gemacht. Sie hat sie zu dem Ort gemacht, an dem die Entscheidungen fallen.

Was ein Gateway nicht löst

Ehrlichkeit schneidet in beide Richtungen — hier die Liste, die wir selbst lesen wollen würden:

Es schreibt Ihre Server nicht um. Wenn Server-Code sampling/createMessage aufruft, muss dieser Code sich ändern. Ein Gateway zeigt, wo; die Arbeit nimmt es Ihnen nicht ab.
Sampling braucht einen echten Ersatz, keinen Shim. Modellzugriff zu einer Provider-API zu verlagern, verschiebt Keys, Budgets und Logging. Entscheiden Sie das bewusst, statt die Deadline entscheiden zu lassen.
Stateful Designs brauchen Redesign, keine Übersetzung. Der Hacker-News-Einwand ist berechtigt: Explizite Handles kosten Schema-Fläche und Tokens gegenüber implizitem Session-Kontext. Die Spec hat sich für Betreibbarkeit entschieden; manche Tool-Designs zahlen dafür.
Bridging kauft Zeit, keine Fertigstellung. Ein Gateway, das beide Revisionen spricht, verlängert die Koexistenz. Die Deprecation-Frist endet trotzdem.
Header-basierte Policy hat eine Vertrauensgrenze. Die Spec selbst warnt Intermediäre, gespiegelten Headern nur zu vertrauen, wenn die deklarierte Protokollversion Header-Body-Validierung erzwingt — und älteren Traffic abzulehnen, statt auf unvalidierte Header zu reagieren. Und Origin-Server sollten ohnehin weitervalidieren: Ein Gateway darf nie der einzige Kontrollpunkt werden.

Wo ToolMesh steht

ToolMesh ist ein selbst gehostetes MCP-Gateway unter Apache-2.0-Lizenz, geschrieben in Go, das zwischen KI-Agenten und Backend-Systemen sitzt und jeden Tool-Call durch eine fail-closed Pipeline führt: authenticate → authorize → inject credentials → gate output → execute → audit. Der Zustand, den die neue Spec aus dem Protokoll drängt, ist genau die Sorte Zustand, die eine Control Plane absichtlich hält: Backend-Credentials werden serverseitig injiziert und reisen nie durchs Modell, und jeder Call landet in einem strukturierten Audit-Log — das Rohmaterial für exakt die oben beschriebene Deprecated-Capability-Inventur. Backends werden in DADL deklariert, YAML-Dateien im Git — der Tool-Katalog ist damit per Konstruktion deterministisch, genau das, was die neuen Caching-Regeln (ttlMs, cacheScope, stabile Reihenfolge) belohnen. Die Säulen hinter dieser Pipeline beschreibt Anatomy of an Enterprise Tool Library.

Unsere eigene Produktionsinstanz spricht heute Streamable HTTP und STDIO; ihre Migration auf 2026-07-28 läuft — Transport, SDK und ein Session-Audit der eigenen Backends. Wir berichten lieber Befunde als Prognosen — die Notizen dazu reichen wir nach, sobald die Migration durch ist.

Wenn Sie MCP-Server betreiben und dasselbe Audit beginnen: Wir vergleichen gern Notizen — die GitHub Discussions sind offen.

Referenz: die Änderungen im Überblick

Jeder Breaking Change mit seiner SEP-Referenz — das Spec-Detail hinter der Zusammenfassung oben:

Änderung	Bedeutung	Referenz
Protokoll-Sessions entfernt — `Mcp-Session-Id` ist weg	Jeder Request kann jede Instanz treffen; Zustand über Calls hinweg wird zu expliziten Handles	SEP-2567
`initialize`/`initialized`-Handshake entfernt	Version, Identität und Capabilities reisen pro Request in `_meta`; optionaler `server/discover`-RPC für Discovery vorab	SEP-2575
`subscriptions/listen` ersetzt den HTTP-GET-Endpoint und `resources/subscribe`	Ein langlebiger Opt-in-Response-Stream liefert Change-Notifications	SEP-2575
`ping`, `logging/setLevel`, `notifications/roots/list_changed` entfernt	Log-Level wird pro Request via `_meta` gesetzt (`io.modelcontextprotocol/logLevel`)	SEP-2575
`Mcp-Method`-/`Mcp-Name`-Header auf Streamable HTTP Pflicht	Intermediäre routen, autorisieren und messen, ohne JSON-Bodies zu parsen	SEP-2243
`ttlMs`/`cacheScope` auf List-Ergebnissen und `resources/read` Pflicht	Tool-Kataloge werden cachebar; `"public"` erlaubt explizit geteilte Caches	SEP-2549
Multi Round-Trip Requests (MRTR) ersetzen server-initiierte Requests	`sampling/createMessage`, `elicitation/create`, `roots/list` werden zu `input_required`-Roundtrips	SEP-2322
Alle Results tragen ein Pflichtfeld `resultType`	`"complete"` oder `"input_required"`; Results älterer Server ohne das Feld gelten als complete	SEP-2322
Tasks verlassen den Kern	Offizielle Extension `io.modelcontextprotocol/tasks`, Polling-basiert	SEP-2663
Roots, Sampling, Logging deprecated	Funktionieren noch mindestens zwölf Monate; Neuimplementierungen sollten sie nicht mehr einsetzen	SEP-2577
Legacy-Transport HTTP+SSE als Deprecated reklassifiziert	Migration auf Streamable HTTP	SEP-2596
Dynamic Client Registration deprecated	Client ID Metadata Documents (CIMD) werden der Registrierungsweg; RFC-9207-`iss`-Validierung gefordert	Changelog

Server müssen zusätzlich Requests ablehnen, deren Routing-Header dem Body widersprechen: HTTP 400 mit JSON-RPC-Fehler -32020, HeaderMismatch.