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 Release Candidate, 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 Release Candidate 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 Release Candidate 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 Release Candidate 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.

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 Release Candidate 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.