MCP wird stateless: Was die neue Version für dich ändert

Das Model Context Protocol (MCP) ist der Standard, über den KI-Agenten mit externen Diensten wie Ticket-Systemen, CRMs oder Zahlungsanbietern sprechen. Mit der Spezifikation 2026-07-28 ist MCP komplett stateless. Server brauchen keine dauerhaft gehaltenen Verbindungen mehr und lassen sich wie ein normaler Webdienst betreiben. Für dich heißt das: weniger Infrastruktur, geringere Betriebskosten und ein einfacherer Weg zu KI-Lösungen, die an deine bestehenden Systeme angebunden sind.

In diesem Artikel erklären wir, was sich technisch geändert hat, was davon für Entscheider relevant ist und wie du bestehende MCP-Server migrierst. Die Grundlage ist der Beitrag im Cloudflare-Blog zur neuen MCP-Version.

Warum MCP für dein Unternehmen relevant ist

Ein KI-Agent ist erst nützlich, wenn er auf echte Daten und Funktionen zugreifen kann. Er soll ein Ticket in Linear anlegen, einen Fehler in Sentry nachschlagen oder eine Rückerstattung vorbereiten. Ohne einen gemeinsamen Standard müsste jede dieser Anbindungen einzeln gebaut werden. MCP löst das: Du stellst deine Funktionen einmal als MCP-Server bereit, und jeder kompatible KI-Client kann sie nutzen.

Für die Unternehmensautomatisierung ist das ein praktischer Hebel. Statt für jedes KI-Tool eine eigene Schnittstelle zu pflegen, baust du eine Anbindung und nutzt sie mit den Clients, die dein Team oder deine Kunden einsetzen. Das senkt den Aufwand im Künstliche Intelligenz Business spürbar.

Das Problem der bisherigen Version

MCP wurde ursprünglich für lokale Anwendungen entworfen. Dort ist eine dauerhafte Verbindung zwischen Client und Server unproblematisch. Als MCP-Server ins Netz wanderten, wurde dieses Modell auf Webinfrastruktur übertragen. Das hatte Folgen für den Betrieb:

• Anfragen mussten per Sticky Session immer zum selben Server geleitet werden.
• Offene Streams mussten gehalten und Nachrichten bei Abbrüchen erneut zugestellt werden.
• Bei Deployments mussten aktive Sessions erst auslaufen oder migriert werden.
• Fiel eine Instanz aus, brachen Sessions ab und Clients mussten sich neu verbinden.

Ein sauber betriebener MCP-Server war damit aufwendiger als ein klassischer Webserver. Gerade für Teams ohne großes Infrastruktur-Know-how war das eine Hürde.

Die wichtigsten Änderungen in MCP 2026-07-28

Keine Sessions mehr im Kern des Protokolls

Der bisherige Handshake mit initialize und initialized entfällt, ebenso der Header Mcp-Session-Id. Jede Anfrage bringt Protokollversion, Client-Identität und Fähigkeiten selbst mit. Der Server nimmt die Anfrage entgegen, führt das Tool aus und liefert das Ergebnis. Es gibt keinen Zustand, der gespeichert werden müsste. Wer vorab wissen will, was ein Server kann, ruft optional server/discover auf.

Dadurch laufen MCP-Server jetzt in einem einzelnen Cloudflare Worker, ohne zustandsbehaftete Infrastruktur. Weniger bewegliche Teile bedeuten geringere Kosten und weniger Fehlerquellen im Betrieb. Die bisherige Komponente McpAgent wird für das Protokoll selbst nicht mehr gebraucht. Durable Objects bleiben sinnvoll, wenn deine Anwendung selbst Zustand benötigt.

Rückfragen ohne offenen Stream

Manchmal braucht ein Server vor dem Abschluss einer Aufgabe mehr Informationen. Ein Deployment-Tool will eine Freigabe für die Produktion. Ein Abrechnungs-Tool will eine Bestätigung, bevor es eine Rückerstattung auslöst. MCP nennt das Elicitation. Früher brauchte das einen offenen Stream.

Jetzt gibt es Multi Round-Trip Requests (MRTR). Der Server antwortet mit einem input_required-Ergebnis und beschreibt, was er braucht. Der Client holt die Antwort ein und wiederholt die Anfrage mit dieser Eingabe. Zwischen den beiden Schritten muss keine Verbindung bestehen. Das ist eine Breaking Change gegenüber dem alten Verfahren, aber deutlich einfacher zu betreiben.

HTTP-Infrastruktur versteht MCP

Bisher steckte die Information, welche Methode aufgerufen wird, nur im JSON-Body. Ein Gateway musste den Body parsen, um zu wissen, ob eine Anfrage ein Tool aufruft oder eine Ressource liest. Die neue Spezifikation verlangt dafür eigene Header:

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

Gateways, Rate Limiter und Web Application Firewalls können damit direkt anhand der Header entscheiden. Du kannst für einzelne Methoden unterschiedliche Regeln festlegen und Metriken pro Tool erfassen, mit den HTTP-Werkzeugen, die du ohnehin einsetzt. Zusätzlich liefern Listen-Ergebnisse jetzt Hinweise wie ttlMs und cacheScope. Clients können Tool-Kataloge dadurch gezielt wiederverwenden.

Strengere Autorisierung

Auch die Sicherheit wurde überarbeitet. Die Reihenfolge der Client-Registrierung ist jetzt klar geregelt:

• Vorregistrierte Clients haben Vorrang, wenn Server und Client bereits in Beziehung stehen.
• Client ID Metadata Documents (CIMD) kommen bei dynamischen Registrierungen zum Einsatz.
• Dynamic Client Registration (DCR) bleibt als Rückfalloption, ist für neue Implementierungen aber veraltet und wird nach Sommer 2027 entfernt.

Dazu kommt die Issuer-Prüfung nach RFC 9207. Der Client vergleicht den Aussteller einer Autorisierungsantwort mit dem Aussteller, den er vor dem Start ermittelt hat. So lassen sich Antworten verschiedener Aussteller nicht verwechseln. Außerdem senden Clients den kanonischen Server-URI als Resource nach RFC 8707. Tokens werden nur für diese Zielgruppe ausgestellt und nur dort akzeptiert.

Ein Lebenszyklus für Features

Neu ist eine formale Einstufung in Active, Deprecated und Removed. Ein veraltetes Feature bleibt mindestens 12 Monate verfügbar, bevor es entfernt werden darf. In dieser Version gelten Roots, Sampling, Logging, Dynamic Client Registration und der alte HTTP+SSE-Transport als veraltet. Neue Funktionen wie MCP Apps, Enterprise-Managed Authorization und Tasks laufen über ein Erweiterungs-Framework und werden erst bei Bedarf Teil des Kerns. Für dich ist das vor allem Planungssicherheit: Du bekommst ein festes Zeitfenster für Umstellungen.

Migration: So gehst du bei bestehenden Servern vor

Die neuen SDKs für TypeScript, Python, Go und C# sind veröffentlicht. Der /mcp-Endpunkt kann sowohl das neue Protokoll als auch stateless Anfragen von Streamable-HTTP-Clients aus 2025 verarbeiten. Die meisten Clients verbinden sich deshalb ohne Konfigurationsänderung neu. Für Clients reicht es oft, die Agents-SDK-Version zu aktualisieren.

Aufwendiger wird es bei Servern, die auf Protokoll-Sessions, Server-zu-Client-Anfragen oder eigenständige Streams angewiesen sind. Hier empfiehlt sich dieser Ablauf:

1. Eine strikt stateless Route neben der bestehenden Route mit Sessions betreiben.
2. Funktionen schrittweise auf die neue Route verlagern.
3. Aktive Sessions auslaufen lassen.
4. Den alten Pfad innerhalb der Deprecation-Phase entfernen.

So bleibt der Betrieb während der Umstellung stabil, und niemand muss an einem festen Stichtag alles auf einmal umbauen.

Erfahrungen aus der Produktion

Der stateless Modus läuft bereits in großem Maßstab. Der Code Mode MCP Server für die gesamte Cloudflare-API nutzt ihn seit Februar. Er skalierte nach Angaben von Cloudflare auf tausende Anfragen pro Sekunde und bediente Milliarden von Tool-Aufrufen.

David Cramer, Mitgründer und Chief Product Officer bei Sentry, berichtet, dass Sentry die neue Version live geschaltet hat, bevor die Spezifikation vom 28. Juli final war. Die Produktion sei dabei nicht ausgefallen. Er hebt hervor, dass die Spezifikation einiges an der Autorisierung und an Tools aufräumt.

Tom Moor, Head of Engineering bei Linear, sieht in der neuen Version eine Verbesserung, die das Hosten eines MCP-Servers einfacher und zuverlässiger macht. Linear hat seinen Server einmal auf dem Standard gebaut, und er funktioniert mit jedem KI-Client, den Nutzer mitbringen. Hunderte Einzelintegrationen sind dafür nicht nötig.

Was das für deine Unternehmensautomatisierung bedeutet

Die Änderungen haben direkte Auswirkungen auf Kosten und Aufwand:

• Geringerer Betriebsaufwand: Ein MCP-Server läuft als gewöhnlicher HTTP-Dienst. Sticky Sessions, Stream-Verwaltung und Session-Migration entfallen.
• Einfachere Skalierung: Ohne Zustand kann jede Anfrage von jeder Instanz bearbeitet werden.
• Bessere Kontrolle: Gateways und Firewalls greifen über Header auf Methode und Tool-Namen zu. Das erleichtert Rate Limits, Monitoring und Zugriffsregeln.
• Planbare Updates: Mindestens 12 Monate Vorlauf bei veralteten Funktionen geben deinem Team Zeit für die Umstellung.

Wenn du KI-Agenten an interne Systeme anbinden willst, etwa an dein ERP, dein Ticketsystem oder deine Wissensdatenbank, sinkt mit der neuen Version die Einstiegshürde. Gleichzeitig solltest du bestehende MCP-Server prüfen, denn manche Funktionen sind jetzt als veraltet markiert.

So unterstützt AI-Guys dich

Wir entwickeln KI-Lösungen für Unternehmen und begleiten dich von der Analyse bis zum Betrieb. Beim Thema MCP prüfen wir mit dir, welche deiner Prozesse sich über Agenten automatisieren lassen und welche Systeme dafür angebunden werden müssen. Wir bauen MCP-Server nach dem neuen Standard oder migrieren bestehende Server, inklusive der Absicherung über OAuth.

Kontaktiere uns für eine kostenlose KI-Beratung. Wir sehen uns deine Ausgangslage an und zeigen dir konkret, wo Automatisierung bei dir den größten Effekt hat.

Hinweis: Dieser Beitrag wurde mit KI-Unterstützung erstellt.