MCP ist jetzt zustandslos. Ihre Agentenarchitektur ist es nicht.

MCP lässt sich ab sofort deutlich einfacher wie gewöhnliche Web-Infrastruktur betreiben.

Die Model Context Protocol Specification 2026-07-28 entfernt Sitzungen auf Protokollebene, schafft den Initialisierungs-Handshake ab und macht entfernte MCP-Aufrufe zu eigenständigen Anfragen. Jede Anfrage kann dadurch auf einer beliebigen Serverinstanz hinter einem Standard-Load-Balancer landen.

Die Ankündigung wurde innerhalb weniger Stunden zu einer der meistdiskutierten Meldungen über Entwickler-Infrastruktur auf X. Die Aufmerksamkeit ist gerechtfertigt. Das Release löst reale Probleme, auf die Teams beim Übergang von lokalen MCP-Experimenten zu gemeinsam genutzten Produktionsdiensten gestoßen sind.

Der wichtigste Architekturpunkt wird dabei leicht übersehen:

MCP ist jetzt zustandslos. Ihre Agentenanwendung ist es nicht.

Für Gründer, CTOs und Produktteams ist das mehr als ein Protokoll-Upgrade. Es ist eine Gelegenheit, bewusst zu entscheiden, wo Workflow-Zustand, Identität, Autorisierung, Wiederherstellung und operative Verantwortung hingehören.

Was sich geändert hat

Frühere MCP-Versionen bauten eine Sitzung zwischen Client und Server auf. Der Client führte einen initialize-Austausch durch, der Server konnte eine Sitzungs-ID vergeben und einige Interaktionen hingen von einer offenen bidirektionalen Verbindung ab.

Das funktionierte, erschwerte aber den entfernten Betrieb. Session-Affinität, Wiederverbindungen, gemeinsam genutzter Sitzungsspeicher, langlebige Verbindungen und ungleichmäßige Last konnten zu Infrastrukturproblemen werden.

Die neue Spezifikation entfernt diese Sitzung auf Protokollebene:

Jede Anfrage enthält Protokollversion, Client-Identität und Fähigkeiten.
Jede kompatible Serverinstanz kann eine Anfrage bearbeiten.
Gateways können Aufrufe über Header für Methode und Tool-Name routen und messen.
Listen von Tools, Prompts und Ressourcen erhalten Cache-Hinweise und eine deterministische Reihenfolge.
Multi Round-Trip Requests ermöglichen zusätzliche Eingaben, ohne einen bidirektionalen Stream offen zu halten.
Ein formales Erweiterungsmodell umfasst MCP Apps, Tasks und Enterprise Managed Authorization.
Mehrere Änderungen härten OAuth und die Prüfung von Ausstellern ab.
Für veraltete Funktionen gilt ein Migrationsfenster von mindestens zwölf Monaten.

Das ist eine wesentliche Vereinfachung. Entfernte MCP-Server passen natürlicher hinter normale Load-Balancer, auf Serverless-Plattformen und in horizontal skalierte Umgebungen.

Die schwierigen Teile eines produktiven Agentensystems verschwinden dadurch nicht. Sie werden sichtbarer.

Zustandsloser Transport bedeutet keine zustandslose Arbeit

Ein Agent, der eine Rechnung prüft, einen Lieferanten recherchiert, ein Repository ändert oder einen Supportfall koordiniert, führt normalerweise einen Workflow aus und nicht nur einen isolierten Funktionsaufruf.

Dieser Workflow muss unter Umständen speichern:

welchem Kunden oder Mandanten der Vorgang gehört;
welche Dateien oder Datensätze bereits verarbeitet wurden;
welche Freigabe noch aussteht;
welche Tools bereits aufgerufen wurden;
welche Seiteneffekte erfolgreich waren;
ob eine Wiederholung sicher ist;
an welcher Stelle ein langer Vorgang fortgesetzt werden soll;
wer die Arbeit einsehen, abbrechen oder übernehmen darf.

Das Entfernen einer impliziten Transportsitzung beseitigt keinen dieser Zustände.

Die Spezifikation erlaubt einem Tool ausdrücklich, eine Referenz zurückzugeben, die das Modell bei späteren Aufrufen erneut übermittelt. Das ist nützlich, doch die Referenz ist nur ein Schlüssel. Dahinter braucht die Anwendung weiterhin ein dauerhaftes, autorisiertes Zustandsmodell.

Das ist gute Architektur. Verborgener Sitzungszustand ist bequem, bis ein Server neu startet, eine Anfrage eine andere Instanz erreicht oder ein Operator den Ablauf rekonstruieren muss. Expliziter Zustand lässt sich bewusst speichern, prüfen, migrieren, verfallen lassen und wiederherstellen.

Gefährlich wird es, wenn eine sichtbare Referenz bereits als vollständige Architektur gilt.

Entscheiden Sie, wohin Zustand gehört

Vor dem Upgrade sollten Teams alle Stellen erfassen, an denen das bestehende System auf Kontinuität angewiesen ist.

Ein Teil des Zustands gehört in den Agenten-Orchestrator: aktueller Plan, Gesprächskontext, Tool-Ergebnisse und der für das Modell sichtbare Fortschritt. Ein anderer Teil gehört in das Geschäftssystem: Auftragsstatus, Freigabe, Supportticket oder Deployment-Anfrage. Wieder ein anderer Teil gehört in eine dauerhafte Workflow-Infrastruktur: Wiederholungszähler, Sperren, Fristen, Checkpoints und Abbruchstatus.

Vermeiden Sie eine zweite, inoffizielle Kopie der Geschäftswahrheit im MCP-Server.

Wenn eine Rechnung freigegeben ist, sollte das Buchhaltungs- oder Workflow-System diese Tatsache besitzen. Wenn ein Deployment genehmigt werden muss, sollte die Delivery-Plattform diese Freigabe verwalten. Der MCP-Server stellt eine kontrollierte Fähigkeit bereit. Er sollte nicht nebenbei zum undokumentierten System of Record werden, nur weil der Agent Kontinuität braucht.

Eine praxistaugliche Architektur trennt drei Aspekte:

Agentenkontext — Informationen, die das Modell für die nächste Aktion braucht.
Workflow-Zustand — dauerhafter Fortschritt, Wiederholungen, Eigentümerschaft und Wiederherstellung.
Geschäftszustand — maßgebliche Datensätze und folgenreiche Entscheidungen.

Diese Aspekte arbeiten zusammen, sollten aber nicht in einem undurchsichtigen Sitzungsobjekt verschmelzen.

Gateways sehen mehr, doch Tools bleiben für Autorisierung verantwortlich

Die neuen Header Mcp-Method und Mcp-Name erlauben einem Gateway, einen Aufruf wie tools/call für ein bestimmtes Tool zu erkennen, ohne den JSON-Body zu parsen.

Das hilft bei:

Routing;
Rate Limits;
groben Zugriffsregeln;
Kostenzuordnung;
Observability;
dem Blockieren unzulässiger Tool-Kategorien.

Für die Autorisierung einzelner Ressourcen reicht es nicht.

Ein Gateway kann wissen, dass ein Benutzer get_customer_record aufrufen darf. Es kann meist nicht entscheiden, ob dieser Benutzer Kundendatensatz 4817 sehen darf, ob angeforderte Felder sensible Daten enthalten oder ob die Anfrage eine Mandantengrenze überschreitet. Dafür muss das Tool die authentifizierte Identität gegen das konkrete Objekt und die aktuelle Geschäftsregel prüfen.

Eine Produktionsarchitektur braucht deshalb beide Ebenen:

Das Gateway entscheidet, ob diese Identität diese Fähigkeit innerhalb der operativen Grenzen erreichen darf.
Das Tool entscheidet, ob die Identität diese konkrete Aktion an dieser konkreten Ressource durchführen darf.

Ein Feld mit Client-Identität ist nicht allein deshalb vertrauenswürdig, weil jede Anfrage sich selbst beschreibt. Identität muss an authentifizierte Zugangsdaten gebunden und über eine überprüfbare Kette weitergegeben werden.

Lang laufende Tasks sind Geschäftsvorgänge

Tasks in ein formales Erweiterungsmodell zu überführen, gehört zu den nützlichsten Änderungen des Releases.

Lang laufende Agentenarbeit ist üblich: eine Codebasis analysieren, einen Bericht erstellen, Daten abgleichen, eine Migration vorbereiten oder auf eine menschliche Freigabe warten. Eine Task-Abstraktion gibt diesen Vorgängen einen saubereren Lebenszyklus als eine einzelne, lange Verbindung.

Ein produktiver Task braucht allerdings mehr als einen Status-Endpunkt.

Definieren Sie:

eine stabile Task-ID;
Mandant und Eigentümer;
Idempotenzregeln;
zulässige Zustandsübergänge;
Fortschritt und letzten Heartbeat;
Abbruchsemantik;
Wiederholungs- und Timeout-Regeln;
erzeugte Artefakte;
menschliche Freigaben;
Audit-Verlauf;
Aufbewahrungs- und Löschregeln.

Kommt dieselbe Anfrage zweimal an, muss das System entscheiden können, ob es den Vorgang fortsetzt, das vorhandene Ergebnis zurückgibt oder einen neuen Vorgang startet. Fällt ein Worker aus, sollte ein anderer sicher übernehmen können. Bricht ein Operator den Task ab, muss der Abbruch nachgelagerte Arbeit tatsächlich stoppen und darf nicht nur ein Datenbankfeld ändern.

Das ist Workflow-Engineering, keine reine Protokollarbeit.

Die Migration sollte parallel und beobachtbar sein

Das Release enthält Breaking Changes. Teams, die Sitzungs-IDs, serverinitiierte Aufrufe, das alte HTTP+SSE-Verfahren, Roots, Sampling oder Logging verwenden, brauchen eine geplante Migration.

Aktualisieren Sie nicht alle Clients und Server in einem einzigen koordinierten Sprung.

Ein sichererer Weg:

Erfassen Sie Clients, Server, SDK-Versionen, Transportverfahren und veraltete Funktionen.
Ergänzen Sie Telemetrie für Protokollversionen, um tatsächlich genutzte Pfade zu erkennen.
Überführen Sie sitzungsabhängigen Zustand in ein explizites, dauerhaftes Modell.
Testen Sie Wiederholungen, doppelte Zustellung, Instanzwechsel und Worker-Neustarts.
Betreiben Sie alte und neue Protokollversion parallel, soweit die Implementierung es zulässt.
Migrieren Sie zuerst risikoarme Nutzer.
Vergleichen Sie Fehlerraten, Latenz, Cache-Verhalten, Autorisierungsentscheidungen und Task-Wiederherstellung.
Entfernen Sie alte Pfade erst, wenn echter Traffic zeigt, dass sie nicht mehr verwendet werden.

Das Migrationsfenster von mindestens zwölf Monaten schafft Luft, ist aber kein Grund, die Bestandsaufnahme aufzuschieben. Der erste Schritt ist zu verstehen, welche Annahmen Ihre aktuelle Integration macht.

Fragen vor der Einführung von MCP 2026-07-28

Für einen Produktionsreview sollten Teams fragen:

Welcher Zustand hängt heute von einer MCP-Sitzungs-ID ab?
Welches System ist für jede Geschäftsentscheidung maßgeblich?
Kann jede kompatible Instanz die nächste Anfrage sicher bearbeiten?
Sind Wiederholungen und doppelte Aufrufe idempotent?
Ist die Identität kryptografisch an jede Anfrage gebunden?
Welche Regeln gehören ins Gateway und welche müssen im Tool bleiben?
Überleben lang laufende Tasks Neustarts und die Übergabe an einen Operator?
Können wir jede folgenreiche Aktion über mehrere Instanzen hinweg rekonstruieren?
Welche veralteten Funktionen sind noch in Gebrauch?
Können Clients und Server unabhängig voneinander migrieren?

Gibt es klare Antworten, sollte die neue Spezifikation die Infrastruktur vereinfachen.

Gibt es sie nicht, hat das Upgrade bereits einen Nutzen geliefert: Es hat Architektur sichtbar gemacht, die zuvor in einer Sitzung verborgen war.

Der eigentliche Vorteil ist operative Klarheit

MCP 2026-07-28 ist nicht wichtig, weil „zustandslos“ modern klingt. Das Protokoll nähert sich bewährten Mustern aus Web- und verteilten Systemen: explizite Anfragen, gewöhnliches Routing, cachebare Discovery, formale Erweiterungen und geplante Ablösung alter Funktionen.

Damit entsteht ein besseres Fundament für produktive Agenten.

Am meisten profitieren Teams, die nicht nur ein SDK aktualisieren. Sie machen Zustand explizit, lassen Geschäftswahrheit im richtigen System, trennen Gateway-Regeln von Ressourcenautorisierung und geben lang laufender Arbeit ein belastbares Betriebsmodell.

Zustandslose Infrastruktur skaliert leichter.

Explizite Architektur macht sie vertrauenswürdig.

McDougall Digital hilft Teams, KI-unterstützte Softwaresysteme über die Prototypenphase hinaus zu entwerfen und zu betreiben. Wenn Ihre MCP-Integration von lokalen Tools zu gemeinsam genutzter Produktionsinfrastruktur wächst, prüfen wir Zustandsmodell, Autorisierungsgrenzen, Migrationspfad und Betriebsmodell, bevor daraus teure Einschränkungen werden.