Die neue MCP-Spezifikation vom 28.07.2026 verzichtet auf alle Anforderungen an den Sitzungsstatus (Session-State), sodass jede Anfrage alle benötigten Daten selbst mitführt. Der Wechsel zu einem zustandslosen (stateless) Protokoll bedeutet, dass Entwickler pro Aufruf eine einzelne Instanz starten können, die auf Serverless- oder Edge-Nodes läuft. Damit entfällt die alte Infrastruktur für Sticky-Routing und Shared-Stores, die bisher oft Probleme bei der Bereitstellung verursachte.

Vom Handshake zu eigenständigen Aufrufen

Bisher erzwang das Model Context Protocol (MCP) einen Handshake, der eine Session-ID ausgab. Server mussten diese ID für die gesamte Dauer der Verbindung speichern, was in der Praxis bedeutete, Prozesse am Leben zu erhalten, den Status über einen Redis-Cluster zu replizieren oder Load Balancer für „Sticky-Routing“ zu konfigurieren. Das Ergebnis war ein komplexer, ressourcenintensiver Stack, der das Skalieren erschwerte und horizontales Wachstum teuer machte.

Die neue Spezifikation macht jede Anfrage in sich geschlossen (self-contained). Jede Payload enthält die Protokollversion und die Identität des Aufrufers, sodass der Server die Anfrage als einmalige Transaktion behandeln kann. Kein Session-Store, keine langlebigen Prozesse, keine speziellen Routing-Regeln.

Warum Zustandslosigkeit für das Deployment entscheidend ist

  • Bereit für Serverless und Edge – Eine Anfrage trägt alles, was sie benötigt, sodass eine Funktion starten, antworten und sich ohne Warm-up-Status wieder beenden kann. Anbieter, die pro Aufruf abrechnen, werden für MCP-Workloads rentabel.
  • Vereinfachtes Load Balancing – Standard-L4/L7-Balancer können den Datenverkehr gleichmäßig verteilen; es ist nicht mehr nötig, einen Client an ein bestimmtes Backend zu binden.
  • Reduzierter betrieblicher Aufwand – Teams können Redis-Cluster oder benutzerdefinierten Code zur Session-Replikation einstellen, was sowohl die Kosten als auch die Fehleranfälligkeit senkt.

Für Organisationen, die MCP bereits hinter einem Load Balancer betreiben, macht die Änderung „Sticky“-Regeln überflüssig, die oft zu einer ungleichmäßigen Lastverteilung führen. Die Einsparungen sind besonders hoch bei Hochdurchsatz-Diensten, die Millionen von Aufrufen pro Tag verarbeiten.

Performance- und Sicherheits-Upgrades

Die Spezifikation fügt konkrete Verbesserungen hinzu, die das Protokoll über seine Zustandslosigkeit hinaus absichern:

  • TTL-basiertes Caching – Tool- und Prompt-Listen enthalten nun ein Time-to-Live-Feld, sodass Clients Ergebnisse lokal zwischenspeichern und unnötige Roundtrips vermeiden können.
  • Header-gesteuertes Routing – Neue HTTP-Header legen Routing-Informationen frühzeitig offen, sodass Gateways den Datenverkehr weiterleiten können, ohne den vollständigen JSON-Body parsen zu müssen, was die Latenz um Millisekunden reduziert.
  • OAuth/OIDC-Härtung – Identitätstoken werden strengeren OAuth- und OpenID Connect-Prüfungen unterzogen, was das Risiko von Replay- und Token-Diebstahl-Angriffen verringert.
  • Formelles Erweiterungs-Framework – Tasks und Apps gehören nun zu einem definierten Erweiterungsmodell, was zukünftige Feature-Rollouts für SDK-Maintainer reibungsloser macht.

Auswirkungen auf Entwickler

Das SDK-Ökosystem spiegelt den Wandel bereits wider: TypeScript-, Python-, Go- und C#-Bibliotheken geben das neue Anfrageformat aus. Die kombinierten Downloads dieser SDKs nähern sich der Marke von einer halben Milliarde pro Monat – das ist viermal mehr als zu Beginn des Jahres, was zeigt, wie weit verbreitet die Einführung von MCP bereits ist.

Entwickler müssen jeglichen Code anpassen, der von einer dauerhaften Sitzung ausging. In der Regel bedeutet dies, sitzungsspezifische Daten in die Request-Payload oder in einen externen Store zu verschieben, der bei jedem Aufruf abgefragt wird. Das Migrationsfenster beträgt zwölf Monate, was Teams Zeit gibt, das neue Muster zu refactoren, zu testen und einzuführen.

Gegenargument: Migrationskomplexität

Zustandslosigkeit ist kein Selbstläufer. Anwendungen, die sich zuvor auf serverseitigen Status für Dinge wie den progressiven Gesprächsverlauf verlassen haben, müssen diesen Status nun clientseitig oder über eine separate Persistenzschicht verwalten.

Worauf man achten sollte

  • Adoptionsmetriken – Überwachen Sie die Akzeptanz der SDK-Versionen; eine Verlangsamung könnte auf Migrationsschwierigkeiten hindeuten.
  • Unterstützung von Edge-Plattformen – Da immer mehr Anbieter MCP-kompatible Laufzeiten ankündigen, wird der tatsächliche Kostenvorteil von Serverless deutlicher werden.
  • Berichte über Sicherheitsvorfälle – Der gehärtete OAuth/OIDC-Flow sollte Identitätsangriffe reduzieren, aber jeder Vorfall wird die neuen Schutzmaßnahmen auf die Probe stellen.

Fazit: Indem die Spezifikation MCP zustandslos macht, richtet sie das Protokoll an modernen Cloud-Native-Mustern aus, reduziert den betrieblichen Ballast des Session-Managements massiv und öffnet die Tür für günstigere, elastischere Deployment-Modelle. Der Kompromiss ist eine kurze Phase des Code-Refactorings und größere Request-Footprints, aber der langfristige Nutzen ist ein Protokoll, das genauso einfach skaliert wie die Infrastruktur, auf der es läuft.