MCP wird zustandslos: Was die Spezifikation 2026-07-28 ändert

Auf LinkedIn bin ich über einen Post gestolpert, der auf einen Artikel von Cloudflare zur neuen MCP-Spezifikation verwies. Die Idee dahinter fand ich spannend genug, um mich tiefer einzulesen, und aus dieser Recherche ist dieser Artikel entstanden.

Wer in den letzten anderthalb Jahren einen MCP-Server gebaut hat, kennt das Gefühl: Lokal über STDIO ist alles schön einfach, aber sobald der Server ins Netz soll, hängt plötzlich eine Menge Infrastruktur dran. Sticky Sessions, offene Streams, Message-Replay. Für etwas, das am Ende meistens nur ein Tool aufruft und ein Ergebnis zurückgibt.

Mit der Spezifikation 2026-07-28 ist das vorbei. MCP ist jetzt ein zustandsloses Protokoll, und die offiziellen SDKs für TypeScript, Python, Go und C# wurden passend dazu überarbeitet. Bei der Recherche hat mich vor allem eine Frage begleitet: Was heißt das für jemanden, der eigene MCP-Server betreibt?

Woher das Problem kam

MCP ist ursprünglich für lokale Anwendungen entstanden. Der erste Transport war STDIO: Client startet Server als Prozess, beide halten die Verbindung, solange sie laufen. Das funktioniert lokal hervorragend.

Als MCP-Server dann remote wurden, hat man dieses Modell fast eins zu eins ins Web übertragen. Am Anfang stand ein initialize/initialized-Handshake, der Server vergab eine Mcp-Session-Id, und jeder weitere Request musste den passenden Zustand wiederfinden. In der Praxis hieß das:

• Autoscaling musste aktive Sessions erhalten.
• Deployments mussten Sessions auslaufen lassen oder migrieren.
• Fiel eine Instanz weg, musste der Client neu verbinden oder hatte eine kaputte Session.

Serverless ging zwar, aber nur mit zusätzlicher Koordination für eine Session, die die meisten Aufrufe gar nicht gebraucht hätten.

Keine Sessions mehr

Die neue Spezifikation streicht den Pflicht-Handshake, den Mcp-Session-Id-Header und Protokoll-Sessions aus dem normalen Request-Ablauf. Jeder Request bringt selbst mit, was er braucht: Protokollversion, Client-Identität und Client-Capabilities. Wer einen Server vorher inspizieren möchte, kann optional server/discover aufrufen.

Damit wird ein MCP-Server zu dem, was er die meiste Zeit ohnehin war: ein HTTP-Endpunkt. Request kommt rein, Tool, Prompt oder Resource wird ausgeführt, Ergebnis geht raus. Nichts muss zwischengespeichert werden. Das macht Deployment, Skalierung und Wartung deutlich einfacher, ohne dass Funktionen verloren gehen.

Elicitation ohne offenen Stream

Manchmal braucht ein Server mitten in einem Aufruf noch eine Information vom Menschen: eine Freigabe für ein Production-Deployment, eine Farbauswahl, die Bestätigung einer Rückerstattung. MCP nennt das Elicitation.

Bisher hing das an einem offenen Stream, über den der Server elicitation/create an den Client schicken konnte. Das bedeutete Abwägungen zwischen Stream-Handling, Kosten und Request-Timeouts.

Neu sind Multi Round-Trip Requests (MRTR). Der Server antwortet mit einem input_required-Ergebnis und beschreibt, was ihm fehlt. Der Client sammelt die Antwort ein und schickt die Operation mit diesem Input erneut. Keine der beiden Seiten muss dazwischen eine Verbindung halten.

Das ist ein Breaking Change gegenüber der alten Elicitation. Ich halte ihn aber für richtig: Das Muster ist viel leichter zu implementieren, und dadurch werden es vermutlich mehr Server tatsächlich nutzen.

HTTP-Infrastruktur versteht MCP

MCP-Requests sind JSON-RPC über HTTP. Bisher stand aber nur im JSON-Body, was ein Request eigentlich tut. Ein Gateway musste den Body parsen, um zu erkennen, ob gerade tools/list oder ein Tool-Aufruf durchläuft.

Jetzt sind bei Streamable HTTP die Header Mcp-Method und Mcp-Name Pflicht:

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

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": { "q": "otters" }
  }
}

Gateways, Rate Limiter und WAFs können damit anhand von Headern entscheiden, ohne beliebiges JSON zu parsen. Regeln pro Methode oder Metriken pro Tool lassen sich mit denselben Mitteln umsetzen wie überall sonst im Web.

Dazu kommen Cache-Hinweise (ttlMs, cacheScope) für tools/list, prompts/list, resources/list und resources/read. Tool-Kataloge sind außerdem deterministisch sortiert. Das klingt nach einem Detail, ist aber praktisch: Clients können den Katalog wiederverwenden, und Prompt-Caches beim Modellanbieter bleiben über Reconnects hinweg stabil.

Authorization wird strenger

Bei der Client-Registrierung gibt es jetzt eine klare Reihenfolge:

• Vorab registrierte Clients, wenn Server und Client sich schon kennen.
• Client ID Metadata Documents (CIMD) für dynamische Registrierungen.
• Dynamic Client Registration (DCR) nur noch als Fallback. DCR ist für neue Implementierungen deprecated und soll nach Sommer 2027 entfallen.

Außerdem übernimmt MCP RFC 9207 (Issuer Identification): Der Authorization Server liefert iss in der Antwort mit, der Client vergleicht es mit dem vorher ermittelten Issuer. So lassen sich Antworten verschiedener Issuer nicht mehr verwechseln. Und Clients senden die kanonische Server-URI als resource nach RFC 8707. Tokens werden für genau diese Audience ausgestellt und nur von ihr akzeptiert.

Ein Lebenszyklus für Features

Fast wichtiger als die technischen Änderungen finde ich den neuen formalen Feature-Lifecycle. Features sind Active, Deprecated oder Removed. Was deprecated ist, muss mindestens zwölf Monate verfügbar bleiben.

In diesem Release deprecated: Roots, Sampling, Logging, Dynamic Client Registration und der alte HTTP+SSE-Transport. Wer sie nutzt, hat also ein klares Zeitfenster für die Migration statt einer Überraschung.

Neue Ideen landen zuerst im Extensions-Framework statt direkt im Kern. MCP Apps und Enterprise-Managed Authorization sind bereits Extensions, Tasks für lang laufende Arbeit wurden dorthin verschoben. So kann der Kern stabil werden, während drumherum weiter experimentiert wird.

Wie ein Server jetzt aussieht

Ein minimaler Server mit dem offiziellen TypeScript-SDK, hier auf Cloudflare Workers mit dem Agents SDK:

import { McpServer } from '@modelcontextprotocol/server'
import { createMcpHandler } from 'agents/mcp/server'
import { z } from 'zod'

function createServer() {
  const server = new McpServer({ name: 'hello-server', version: '1.0.0' })

  server.registerTool(
    'hello',
    {
      description: 'Return a greeting',
      inputSchema: { name: z.string().optional() },
    },
    async ({ name }) => ({
      content: [{ type: 'text', text: `Hello, ${name ?? 'World'}!` }],
    }),
  )

  return server
}

export default {
  fetch(request, env, ctx) {
    return createMcpHandler(createServer)(request, env, ctx)
  },
}

Kein Durable Object, keine Session-Verwaltung, nur eine fetch-Funktion. Zustand braucht man nur noch, wenn die eigene Anwendung ihn braucht, nicht mehr, weil das Protokoll es verlangt.

Erwähnenswert: Das TypeScript-SDK basiert inzwischen auf Web Standards statt auf Node.js. Es läuft dadurch sauber auf Bun, Deno und Workers, und die Bundles sind kleiner.

Migration

Die gute Nachricht zuerst: Der /mcp-Endpunkt akzeptiert sowohl das neue Protokoll als auch zustandslose Requests von Streamable-HTTP-Clients aus 2025. Die meisten Clients verbinden sich also ohne Konfigurationsänderung neu.

Aufwendiger wird es nur für Server, die wirklich auf Sessions, Server-zu-Client-Requests oder eigenständige Streams angewiesen sind. Der empfohlene Weg:

• Neue, strikt zustandslose Route neben die bestehende stellen.
• Features nach und nach umziehen.
• Aktive Sessions auslaufen lassen.
• Alte Route innerhalb der Deprecation-Frist entfernen.

Mein Fazit

Die Kritik an MCP war berechtigt: Für die allermeisten Aufrufe war die Session-Infrastruktur reiner Overhead. Mit 2026-07-28 wird ein MCP-Server zu einem gewöhnlichen HTTP-Workload, der sich mit den üblichen Werkzeugen skalieren, absichern und beobachten lässt. Dass Sentry und Linear die neue Version schon vor der Finalisierung in Produktion hatten, spricht dafür, dass der Umstieg in der Praxis funktioniert.

Für eigene Server heißt das vor allem: weniger Infrastruktur, und Rückfragen an den Menschen bei Bedarf über MRTR statt über offene Streams.