MCP 2026-07-28: Was das zustandslose Protokoll für B2B-Agenten-Deployments bedeutet

Warum dieser Release die Deployment-Mathematik verändert

Das Model Context Protocol (MCP) ist ein offener Standard zur Verbindung von KI-Agenten mit externen Systemen. Am 28. Juli 2026 erscheint seine größte Revision seit dem Launch — ein endgültige Spezifikation, der die Protokollschicht zustandslos macht, Erweiterungen erster Klasse einführt und drei Features als veraltet markiert, die Komplexität hinzufügten, ohne sich in der Produktion zu rechtfertigen.

Für Teams, die MCP-Server hinter B2B-Agentensystemen betreiben, ist die praktische Auswirkung konkret: Sie benötigen keine persistenten Sitzungen, keine gemeinsamen Session-Stores und keine session-aware Load Balancer mehr. Der Zustand, den ein Agent über mehrere Werkzeugaufrufe hinweg benötigt, wird zu einem expliziten Handle — sichtbar für das Modell, auditierbar in den Logs und zwischenspeicherbar durch Zwischenstationen. Dieser Artikel geht die Änderungen durch, die für B2B-Deployments wichtig sind, und wie sie sich auf das MCP-Modul-Muster abbilden, das wir bereits ausliefern.

Die zustandslose Protokollschicht

Die zentrale Änderung: Der initialize / initialized-Handshake und der Mcp-Session-Id-Header werden entfernt. Anfragen sind nun in sich geschlossen. Protokollversion, Client-Informationen und Fähigkeiten reisen in _meta mit jeder Anfrage, nicht in einer ausgehandelten Session, an die sich der Server erinnern muss.

Was dies in einem B2B-Deployment eliminiert:

• Load Balancer mit persistenten Sitzungen. Remote-MCP-Server können hinter einfachen Round-Robin-Load-Balancern stehen. Jede Serverinstanz kann jede Anfrage behandeln, da kein serverseitiger Zustand erforderlich ist, um sie zu interpretieren.
• Gemeinsame Session-Stores. Wenn Sie heute horizontal skalieren, benötigt jede MCP-Serverinstanz Zugriff auf denselben Session-Zustand — typischerweise Redis oder eine Datenbank. Das zustandslose Protokoll entfernt diese Abhängigkeit.
• Session-Replay-Infrastruktur. Wenn eine Session mitten in einem Workflow abbricht, muss der Client neu initialisieren und den Kontext wiederherstellen. Das zustandslose Protokoll hat keine Session, die abbrechen kann; jede Anfrage trägt alles mit, was sie benötigt.

Die Deployment-Form wird einfacher: ein Pool zustandsloser MCP-Serverinstanzen hinter einem Load Balancer, ohne gemeinsame Zustandsschicht dazwischen. Das ist dieselbe Form wie jede zustandslose HTTP-API — erprobt, observierbar und günstig zu skalieren.

Das explizite-Handle-Muster für zustandsbehaftete Workflows

Zustandslos bedeutet nicht, dass Zustand verschwindet. Workflows, die mehrere Werkzeugaufrufe umspannen — eine RFQ-Erfassung, eine Angebotverhandlung, eine Verfügbarkeitsreservierung — benötigen weiterhin Kontinuität. Der endgültige Spezifikation ersetzt versteckten Session-Zustand durch das explizite-Handle-Muster: ein Werkzeug erzeugt ein Handle (eine order_id, eine quote_id, eine basket_id) und das Modell gibt es als gewöhnliches Argument bei nachfolgenden Aufrufen zurück.

Dies ist eine bedeutsame Veränderung für B2B-Deployments aus drei Gründen.

Zustand ist für das Modell sichtbar. Heute lebt der Session-Zustand in Transport-Metadaten, die das LLM nie sieht. Mit expliziten Handles hält und referenziert das Modell das Handle in seinem Räsonieren. Wenn das Modell get_quote(quote_id="q-7f3a") aufruft, weiß es, auf welches Angebot es sich bezieht. Dies verbessert die Genauigkeit der Werkzeugauswahl in mehrstufigen Workflows.

Zustand ist in den Logs auditierbar. Jede Anfrage trägt ihr Handle im Anfragekörper, nicht in einem Header, den der Anwendungs-Logger entfernt. Ein Audit-Trail kann den vollständigen Workflow-Zustand zu jedem Zeitpunkt rekonstruieren, indem er die Anfrageargumente liest — es ist keine Korrelation mit Session-Store-Logs erforderlich.

Zustand ist durch Zwischenstationen zwischenspeicherbar. Da das Handle Teil der Anfrage ist, kann eine Gateway- oder Cache-Schicht danach schlüsseln. Listen- und Ressourcenergebnisse enthalten ttlMs- und cacheScope-Felder, sodass eine Katalogabfrage mit einem stabilen Handle aus dem Cache bedient werden kann, ohne das Upstream-System zu erreichen.

Wie sich dies auf einen RFQ-Workflow abbildet

Betrachten Sie einen Angebotsworkflow, der über fünf Werkzeugaufrufe läuft: Anfrage erstellen, Katalog durchsuchen, Angebot erstellen, Verfügbarkeit reservieren, Preisstufe anwenden. Unter dem session-basierten Protokoll teilen sich diese fünf Aufrufe eine serverseitige Session. Unter dem expliziten-Handle-Muster:

1. create_request(buyer_id, line_items) → request_id="r-1042"
2. search_catalog(request_id="r-1042", query="industrial pump 220V")
3. generate_quote(request_id="r-1042", supplier_ids=["s-12", "s-19"])
       → quote_id="q-7f3a"
4. hold_availability(quote_id="q-7f3a", hold_duration="48h")
       → hold_id="h-3391"
5. apply_pricing_tier(quote_id="q-7f3a", tier="volume-3")

Jeder Aufruf trägt das Handle, das er benötigt. Kein Server merkt sich etwas zwischen Aufrufen. Wenn der Load Balancer Aufruf 4 an eine andere Instanz routet als Aufruf 3, funktioniert es dennoch — das Handle ist in der Anfrage. Wenn das Audit-Team diesen Workflow eine Woche später rekonstruieren muss, erzählen die Handles in den Anfrageargumenten die vollständige Geschichte.

Erweiterungen: erster Klasse und unabhängig versioniert

Der endgültige Spezifikation führt Erweiterungen als Konzept erster Klasse ein. Erweiterungen erhalten Reverse-DNS-Bezeichner (z. B. com.example.workflow), verfügen über eigene ext-*-Repositories, haben delegierte Maintainer und werden unabhängig vom Kernprotokoll versioniert.

Die ersten beiden Erweiterungen sind konkret:

• MCP Apps — serverseitig gerenderte HTML-UIs, die in Sandbox-Iframes ausgeliefert werden. Ein MCP-Server kann eine UI ausliefern, die der Client rendert, und ermöglicht damit menschliche Freigabeoberflächen, ohne dass der Client ein eigenes Frontend baut.
• Tasks — langlaufende Arbeiten mit Task-Handles. Ein Werkzeug kann sofort ein Task-Handle zurückgeben und der Client fragt den Abschluss ab, anstatt eine Verbindung für Minuten offen zu halten.

Für B2B-Deployments sind MCP Apps dort relevant, wo ein Mensch eine Transaktion freigeben muss, bevor der Agent fortfährt — eine Bestellung über einem Schwellwert, ein Angebot mit nicht standardmäßigem Rabatt. Die Freigabeoberfläche kann mit dem MCP-Modul ausgeliefert werden, anstatt ein separates Frontend zu benötigen. Tasks sind relevant für Workflows, die ein einzelnes Anfrage-Timeout überschreiten: ein Lieferantenangebot, das 90 Sekunden bis zur Erstellung dauert, ein Katalog-Sync, der Minuten läuft.

Deprecations: Roots, Sampling, Logging

Drei Features werden als veraltet markiert (nur Annotation für 12 Monate; die Entfernung erfordert einen separaten Standardisierungsprozess):

• Roots → ersetzt durch Werkzeugparameter und Ressourcen-URIs. Roots war ein Weg für Clients, Server über Dateisystemorte zu informieren; dieselbe Intention wird jetzt als Argumente an Werkzeuge ausgedrückt, die Dateien lesen.
• Sampling → ersetzt durch direkte LLM-Provider-API-Integration. Server, die LLM-Aufrufe benötigen, rufen den Provider direkt auf, anstatt den Client aufzufordern, einen Sampling-Roundtrip durchzuführen.
• Logging → ersetzt durch stderr und OpenTelemetry. Server-Logging verlagert sich auf Standard-Prozessausgabe und verteiltes Tracing, nicht auf den MCP-Logging-Kanal.

Die Deprecation von Logging ist für B2B-Deployments am relevantesten. Das Audit-Logging-Muster — bei dem jeder Werkzeugaufruf Anfrage, Antwort, Latenz und Ergebnis protokolliert — richtet sich nun an OpenTelemetry aus statt an einen protokollspezifischen Logging-Kanal. Das bedeutet, dass MCP-Server-Logs sich in bestehende Observability-Pipelines (Datadog, CloudWatch, Honeycomb) integrieren, ohne ein eigenes Transportprotokoll.

Routbar, zwischenspeicherbar, nachverfolgbar

Drei Ergänzungen, die den Produktionsbetrieb beeinflussen:

• Die Header Mcp-Method und Mcp-Name ermöglichen Gateway-Routing ohne Body-Inspektion. Ein Gateway kann nach Methode und Werkzeugname auf Header-Ebene routen — kein JSON-Parsing in der Routing-Schicht.
• ttlMs und cacheScope bei Listen-/Ressourcenergebnissen geben Zwischenstationen einen Standard-Caching-Vertrag. Eine Katalog-Listen-Antwort kann eine TTL von 5 Minuten deklarieren, und jedes Gateway im Pfad kann diese einhalten.
• Die Propagierung des W3C Trace Context ist für OpenTelemetry-Kompatibilität dokumentiert. Ein Trace, der vom Agenten-Client gestartet wurde, propagiert durch den MCP-Server und in Upstream-Systemaufrufe, sodass ein einzelner RFQ-Workflow als ein Trace über alle Systeme hinweg erscheint, die er berührt.

Für ein B2B-Deployment, das MCP-Server für NetSuite, HubSpot und einen Lieferantenkatalog betreibt, bedeutet dies: ein Gateway kann nach Werkzeugname routen, ohne Bodies zu parsen, Katalogantworten für eine deklarierte TTL zwischenspeichern und eine einzelne Angebotsanfrage vom Agenten bis zum ERP und zur Lieferanten-API in einem einzigen Span-Baum nachverfolgen.

Härtung der Autorisierung für die Eins-zu-Vielen-Form

Der endgültige Spezifikation verbessert OAuth und OpenID Connect für die Deployment-Form, die B2B-Agentensysteme tatsächlich verwenden: ein Client (der Agent), der sich mit vielen Servern verbindet (NetSuite, HubSpot, BigCommerce, ein Lieferantenkatalog). Token-Refresh, Scope-Verwaltung und die Handhabung mehrerer Server-Anmeldedaten werden in der Spezifikation behandelt, anstatt jeder Integration zu überlassen, dies unabhängig zu lösen.

Dies ist wichtig, weil B2B-Agentensysteme sich nicht mit einem System verbinden. Ein typischer RFQ-Agent verbindet sich mit einem ERP (NetSuite), einem CRM (HubSpot), einer E-Commerce-Plattform (BigCommerce) und zwei oder drei Lieferantenkatalogen — jeder mit seinem eigenen OAuth-Flow, Token-Lebensdauer und Scope-Set. Das Protokoll stellt nun ein Standardmuster zur Verfügung, um diese Komplexität zu verwalten, anstatt dass jedes MCP-Modul seinen eigenen Anmeldedaten-Lebenszyklus implementiert.

Update — 2026-08-06: Terraform MCP CVE-2026-16496 (CVSS 10.0) — the stateless thesis validated in production

HashiCorp patched CVE-2026-16496 (CVSS 10.0) in Terraform MCP Server before version 1.1.0 — the first maximum-severity CVE in the MCP ecosystem. The vulnerability is an authorization bypass in the streamable-HTTP stateful transport mode: a user who obtains another user's MCP session ID can have their tool calls executed using that user's Terraform credentials. HashiCorp also patched CVE-2026-16498 (tenant isolation break) and CVE-2026-14869 (SSRF) in the same release. (The Hacker News, SentinelOne vulnerability database)

This CVE is the first production evidence that the stateful transport mode is a security liability, not just an operational complexity — and it validates the core thesis of this article. The stateless protocol layer the July 28 final specification introduced exists precisely to eliminate the server-side session state that this attack exploits. The attack vector (session-ID theft leading to credential reuse) exists only because the server holds a session state that an attacker can steal and reuse. A stateless server has no session to steal. The explicit-handle pattern this article describes — where stateful workflows mint handles that travel in the request body, not in a server-side session — is the architecture that closes this vulnerability class. The vulnerability affects only the stateful streamable-HTTP transport mode; the stateless protocol core is not affected.

For B2B deployments, the implication is direct: if your MCP servers run stateful streamable-HTTP with Mcp-Session-Id, they carry the session-hijacking attack surface that CVE-2026-16496 exploits. Migrating to the stateless protocol core (Control 1 in the MCP Security Hardening Checklist) eliminates the attack surface at the architecture level, not the patch level. The 12-month SSE deprecation window is now a security deadline, not just an operational one.

Sicherheit: drei neue Angriffsflächen und ein Defense-in-Depth-Datenpunkt

Das zustandslose Redesign führt drei neue Angriffsflächen ein, die von backslash.security in ihrer Same-Day-Analyse der endgültigen Spezifikation identifiziert wurden:

• Handle-Hijacking. Explizite Handles ersetzen den serverseitigen Session-Zustand, aber ein Handle ist ein gewöhnliches Argument. Wenn der Handle-Raum vorhersehbar ist oder dem Transport Integritätsschutz fehlt, kann ein Angreifer, der ein Handle beobachtet oder errät, es in seine eigenen Anfragen injizieren — und sich als Workflow-Eigentümer ausgeben. Die Lösung ist kryptografische Handle-Generierung (zufällig, nicht erratbar) und die Bindung von Handles an den authentifizierten Aufrufer, nicht nur an den Anfrage-Body.
• Dateisystem-Scope-Lücke. Die Deprecation von Roots entfernt die clientseitige Dateisystem-Grenzdeklaration. Tools, die Dateien lesen, erhalten nun Pfade als Argumente, aber ohne die Roots-Grenze kann ein Tool auf Dateisystemorte zugreifen, die der Client nie freigeben wollte. Die Lösung ist pro-Tool-Pfadvalidierung gegen eine explizite Allowlist, nicht die Abhängigkeit von einer Protokoll-Level-Grenze, die nicht mehr existiert.
• MCP Apps HTML-Rendering. Die MCP Apps-Erweiterung ermöglicht es Servern, HTML-UIs in Sandboxed Iframes auszuliefern. Die Sandbox ist eine Sicherheitsgrenze, aber der HTML-Inhalt kommt vom Server — ein kompromittierter oder bösartiger MCP-Server kann eine UI ausliefern, die versucht, die Sandbox zu verlassen oder den Benutzer zu phishing. Die Lösung ist, MCP Apps HTML als nicht vertrauenswürdigen Inhalt zu behandeln: strikte Content Security Policy, kein Same-Origin-Zugriff und Benutzerbestätigung vor dem Rendern von App-Oberflächen neuer Server.

Ein Defense-in-Depth-Datenpunkt: Claude Opus 5 mit aktiviertem Auto Mode erreichte eine 0% Browser-basierte Prompt-Injection-Angriffs-Erfolgsrate über 129 Test-Szenarien — der erste konkrete Datenpunkt, der zeigt, dass Browser-Agent-Prompt-Injection auf null reduziert werden kann. Auto Mode kombiniert einen Eingabe-Layer-Prompt-Injection-Probe mit einem Ausgabe-Layer-Aktions-Klassifikator. Für zustandslose MCP-Deployments, in denen Browser-Agenten MCP-Tools aufrufen, ist das Input-Scanning + Task-Blocking-Muster eine konkrete Defense-in-Depth-Implementierung, die das zustandslose Design des Protokolls erleichtert: jede Anfrage ist in sich geschlossen, sodass Probe und Klassifikator auf jede Anfrage unabhängig operieren, ohne Session-Zustand zu korrumpieren.

Was sich für bestehende MCP-Module ändert

Wenn Sie bereits MCP-Module ausliefern — zum Beispiel das 38-Werkzeug-RFQ-Prozessor-Muster, bei dem Werkzeuge über MCP_CONFIGURATION registriert werden und Domain-Mixins über einen gemeinsamen GraphQL-Client komponieren — ändert das zustandslose Protokoll das Deployment, nicht den Modulcode.

Die Werkzeugregistrierung des Moduls, die Eingabe-/Ausgabeschemas, die Ratenbegrenzung und das Audit-Logging bleiben gleich. Was sich ändert:

• Keine Session-Initialisierung beim Start. Das Modul nimmt an keinem initialize-Handshake teil. Es empfängt Anfragen mit _meta, das Protokollversion und Fähigkeiten trägt, und antwortet.
• Zustandsbehaftete Werkzeuge erzeugen Handles. Wenn ein Werkzeug heute auf eine serverseitige Session angewiesen ist, um einen mehrstufigen Workflow zu verfolgen, sollte es ein explizites Handle erzeugen und zurückgeben. Der Client gibt es beim nächsten Aufruf zurück. Für einen RFQ-Prozessor sind request_id, quote_id und hold_id bereits die Handles — das Muster ist der Domain natürlich.
• Logging verlagert sich zu OpenTelemetry. Wenn das Modul über den MCP-Logging-Kanal protokolliert, migrieren Sie zu stderr und OpenTelemetry-Spans. Der Audit-Inhalt (Anfrage, Antwort, Latenz, Ergebnis) bleibt; das Transportmedium ändert sich.
• Caching ist deklarativ. Listen- und Ressourcen-Endpunkte können ttlMs und cacheScope in ihren Antworten deklarieren und ermöglichen Zwischenstationen das Caching, ohne raten zu müssen.

Das Fazit für B2B-Teams

Das zustandslose Protokoll reduziert die Infrastruktur, die ein MCP-basiertes Agenten-Deployment benötigt. Sie tauschen persistente Sitzungen und gemeinsame Session-Stores gegen explizite Handles in Anfrageargumenten — ein Tausch, der das System einfacher zu skalieren, leichter zu auditen und mit Standardwerkzeugen besser observierbar macht.

Wenn Ihr Team den Umfang eines MCP-basierten Agenten-Deployments plant, ist der endgültige Spezifikation vom 28. Juli die Zielversion. Die Gestaltung für explizite Handles von Anfang an vermeidet die spätere Migration vom session-basierten Zustand.

---

Ein Distributor, der NetSuite, BigCommerce und drei Lieferantenkataloge betreibt, erhält einen Agenten, der eine RFQ per E-Mail oder Portal empfängt, Produkte und Substitute gegen den Katalog-Graphen auflöst, Preise nach Kundensebene festlegt, Bestand mit einer Frist reserviert und das angenommene Angebot zurück nach NetSuite schreibt — mit jedem Schritt protokolliert. Dieser Build ist Phase 2-3 der Vier-Schritte-Methode und ist typischerweise in 5-8 Wochen live.

Angebot für ein abgegrenztes Build anfordern. Einwöchige Discovery. Sie erhalten ein Systeminventar, eine Workflow-Karte und einen festen Umfang — ob Sie mit uns bauen oder nicht.