Was ist Stateless MCP? Stateless-Architektur 2026, JSON-RPC und Remote Server erklärt

Was MCP und Stateless lösen

MCP beantwortet, wie ein Modell externe Fähigkeiten sicher und auffindbar aufruft. Clients (Claude, ChatGPT, IDE-Agents) brauchen einen Standard zum Auflisten von Tools, Lesen von Ressourcen, Laden von Prompt-Vorlagen; Server (GitHub, DBs, interne APIs über MCP-Adapter) brauchen einen Standard, diese Fähigkeiten ohne Custom-Plugin pro Client anzubieten.

Frühes MCP behielt Sessions auf der Transportschicht: Der Client sendet zuerst initialize, der Server liefert Capabilities, spätere Requests tragen Mcp-Session-Id und pinnt Traffic an eine Instanz oder einen shared Session Store. Für lokales stdio ok; sobald Remote Server horizontal skalieren, auf Cloud Run / Lambda laufen oder über API-Gateway pro Tool limitiert werden, wird Session-Stickiness zum Engpass.

Die Spec 2026-07-28 (Release Candidate) macht die Protokollschicht stateless: Metadaten für beliebige Requests stecken im Request; jede Instanz hinter normalem Round-Robin-Load-Balancing kann annehmen. Offizielle Hinweise: MCP-2026-07-28-Spec-Ankündigung und Statelessness-Abschnitt.

Was die Stateful-Ära hinterließ

Im alten Ablauf machten Streamable-HTTP-Clients meist zuerst einen Handshake:

1. Senden: initialize — Protokollversion und Client/Server-Capabilities tauschen.
2. Empfangen der initialized-Benachrichtigung; der Server liefert den Mcp-Session-Id-Response-Header.
3. Danach müssen tools/call und resources/read dieselbe Session ID tragen, sonst findet Gateway oder Instanzspeicher keinen Kontext.

Typische Produktionskosten: Sticky Sessions am Load Balancer; Redis für Sessions zwischen Replikas; nach Serverless-Cold-Start tote Sessions; beliebte Server wie GitHub MCP mussten Redis pflegen. Google nennt in Scaling AI Agent Infrastructure diese Änderung „den größten Spec-Shift seit MCP-Start“ — Kern: Transportschicht-Session-Management streichen.

Stateless-Kern 2026-07-28

Die Spec-Definition von „stateless“ ist hart: Der Server darf nicht aus früheren Requests derselben Verbindung Protokollversion, Client-Identität oder Capabilities ableiten; jeder Request muss das in _meta mitführen. Requests mehrerer Tasks, Threads oder Gespräche können sich auf dem Transport überlagern; Verbindung oder stdio-Prozess sind keine Session-Grenze.

Der Client setzt in jedem Request in params._meta (oder gleichwertig):

• io.modelcontextprotocol/protocolVersion — Pflicht, z. B. 2026-07-28.
• io.modelcontextprotocol/clientCapabilities — Pflicht; leeres Objekt = keine optionalen Capabilities.
• io.modelcontextprotocol/clientInfo — empfohlen für Logs/Debug (Server nicht für Sicherheit nutzen).

Will der Client Server-Capabilities zuerst kennen, ruft er server/discover RPC auf — das ist nicht Pflicht — jeder Request kann der erste auf beliebiger Instanz sein. Server können tools/list zu Antworten wie ttlMs setzen, damit Clients die Tool-Liste im TTL cachen.

Geschäftsstate über mehrere Tool-Calls (Warenkorb, Browser-Session, Ticket-Entwurf) gehört nicht in eine Transport-Session. Wie normale HTTP-API: Tool liefert expliziten Handle (basket_id und draft_id), Modell gibt ihn in späteren tools/call-Argument-JSON zurück. Modell sieht den Handle — leichter zu debuggen als Black-Box-Session.

Wie JSON-RPC in MCP läuft

Die MCP-Nachrichtenschicht bleibt JSON-RPC 2.0: Jeder Request hat jsonrpc und id und method und params; Antworten tragen result oder error; Notifications haben kein id. Gleiche Form wie „Toolname + Argumentobjekt“ im Apple-Agent-Artikel — MCP standardisiert den Methodennamen zu tools/call, mit name und arguments.

Ein typischer stateless tools/call sieht so aus (HTTP-Header im nächsten Abschnitt):

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

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "searchInvoices",
    "arguments": {
      "status": "unpaid",
      "limit": 10
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {},
      "io.modelcontextprotocol/clientInfo": {
        "name": "jsonvue-demo",
        "version": "1.0.0"
      }
    }
  }
}

Bei Erfolg enthält result meist ein content-Array mit Tool-Output (oft type: text-JSON-String oder strukturierter Block). Bei Fehler trägt JSON-RPC error code und message; unter Streamable HTTP bei Abweichung von HTTP-Header und Body method/name verlangt die Spec einen -32020-Header-Mismatch-Fehler.

Für JSONVue-Leser lohnt sich arguments: Externe Agents senden Zahlen als Strings oder lassen Pflichtkeys weg. Stateless MCP nicht Ihr Geschäfts-JSON nicht — gleiche Arbeitsteilung: Structured Output für Modellausgabe, MCP für Tool-Calls. Auf der Site erklärt Apple-AI-Agenten und JSON, dass dieselbe Domänenfunktion App Intent, Foundation Models Tool und MCP bedienen kann — nur der Adapter unterscheidet sich.

Remote Server und Streamable HTTP

Remote MCP Server ist ein MCP-Endpoint über HTTPS, kein lokaler stdio-Subprozess. Streamable HTTP ist der Haupttransport für Remote: Ein POST kann einen RPC abschließen; lange Tasks können offene Notification-Streams liefern, State bleibt aber request-scoped, nicht connection-level Session.

Ab 2026-07-28 müssen Streamable-HTTP-Requests müssen Header wie der Body tragen (SEP-2243), damit Gateway, WAF und Rate Limiter ohne JSON-Parse routen:

• MCP-Protocol-Version — muss _meta protocolVersion entsprechen, sonst 400.
• Mcp-Method — entspricht JSON-RPC-method, z. B. tools/call.
• Mcp-Name — Tool-, Prompt- oder Ressourcenname, z. B. searchInvoices.

Deployment wird einfacher: gleiches Docker-Image, mehrere Replikas, ALB/nginx Round-Robin; Cloud Run / Cloud Functions ohne extra Redis-Session für MCP; QPS-Kontingente pro Mcp-Name sind günstiger als Deep-Body-Inspection. Produktionsdienste wie GitHub MCP Server migrieren bereits.

Lokaler stdio-Server bleibt gültig; Spec klar: Unrelated Requests können sich auf demselben stdio-Prozess überlagern; Server darf Prozessidentität nicht als Session-ID nehmen. Lokal und Cloud-Remote teilen dieselbe Tool-Implementierung — nur Transportadapter unterscheidet sich.

Anwendungen dürfen stateful bleiben

„Stateless im Protokoll“ ≠ „stateless im Geschäft“. Warenkörbe, Mehrstufen-Freigaben, halb ausgefüllte Browser-Formulare dürfen und sollen stateful bleiben — State muss explizit sein, nicht an Mcp-Session-Id gebunden.

Empfohlenes Muster:

1. Erster Tool-Call erstellt Ressource, liefert { "draftId": "dr_8k2", ... }.
2. Tool-Beschreibung: spätere Schritte müssen draftId.
3. Server schlägt draftId in DB/Cache nach; bei Miss JSON-RPC-Geschäftsfehler, kein mysteriöser Session-404.

Bei langen Tasks unterstützen Tasks-Erweiterungen MRTR (Multi-Request Task Routing): Tool kann zuerst status: input_required liefern; Client hängt Nutzerantwort an _meta späterer Requests. Weiter Request/Response auf stateless Protokoll — Antwort kann mehrere Runden dauern.

Bezug zu Structured Output

MCP und Structured Output lösen verschiedene Schichten, aber JSON-Formen treffen sich oft in derselben Agent-Pipeline:

Best Practice: eine Feld-Tabelle pflegen, daraus MCP-Tool-inputSchema, REST-OpenAPI und Structured-Output-Schema fürs Modell erzeugen. der Gemini-API-JSON-Anleitung für Modellseite; das Gemini-Structured-Output-Tutorial mit Cloud-Beispielen. Nach Stateless MCP können Clients Tool-Listen cachen — bei Schema-Versionswechsel Toolname oder Protokollversion bumpen, damit stale Cache keine falsche Form in arguments.

JSON in Produktion prüfen

Beim Debuggen eines Remote MCP Server drei JSONs nebeneinander: Client-tools/call-Argumente, HTTP-Body Ihres Domänendienstes, result.content ans Modell. Bei Formabweichung liegt es fast immer im Adapter, nicht am „nicht smart genug“-Modell.

Im Browser durchgehen: JSON-Formatierung zum Parse-Check; JSON validieren für Trailing Commas und Typfehler; JSON Schema für gemeinsame Felder von Tool-inputSchema und API-Body; JSON Diff„Modell-Arguments“ vs. „echter HTTP-Request-Body“ vergleichen. Drei Fixtures: mcp-args.valid.json und http-body.valid.json und mcp-tool-error.json — dasselbe Schema in CI.

Häufige Fragen FAQ

Fazit und nächste Schritte

Stateless MCP holt Remote Server 2026 zurück ins normale HTTP-Betriebsmodell: JSON-RPC 2.0 trägt Methoden, _meta Protokollkontext, Mcp-Method / Mcp-Name-Header lesbar fürs Gateway. initialize und Mcp-Session-Id weichen — jede Instanz, Serverless-freundlich, einfacheres Rate-Limit pro Tool.

Geschäftsstate als explizite IDs in arguments; JSON-Verträge lokal prüfen. Nächste Schritte: Remote-Endpoint gegen Spec 2026-07-28 (_meta und HTTP-Header vollständig); MCP-Arguments und REST-Body an ein Schema; Round-Trip-JSON im Browser mit JSONVue prüfen.