MCP Streamable-HTTP-Transport — für produktive Mandanten-Deployments

Der Streamable-HTTP-Transport von MCP, eingeführt in der Model-Context-Protocol-Spezifikationsrevision vom März 2025 und Nachfolger des ursprünglichen reinen SSE-Transports, ist das produktive Wire-Format, um MCP-Tools über ein Netzwerk an entfernte Agent-Clients auszuliefern. Ein einzelner HTTPS-Endpunkt nimmt JSON-RPC-2.0-Anfragen per POST entgegen; der Server antwortet mit einer einfachen JSON-Antwort für einen einmaligen Tool-Aufruf oder hebt dieselbe Verbindung auf einen Chunked-Event-Stream, wenn ein Tool Teilergebnisse, Fortschrittsmeldungen oder ein langlebiges Abonnement liefern muss. Der Transport ist standardmäßig zustandslos — jede Anfrage trägt ihre vollständige JSON-RPC-Payload und kann im Prinzip auf jeder Backend-Instanz landen —, unterstützt aber zustandsbehaftete Sitzungen über einen beim initialen Handshake ausgehandelten Session-ID-Header, für die Fälle, in denen Kontinuität über mehrere Anfragen hinweg tatsächlich benötigt wird.

Warum es das gibt

Der ursprüngliche MCP-Transport war rein SSE-basiert: Ein dauerhafter Server-zu-Client-Event-Stream trug alle vom Server ausgehenden Nachrichten, während Client-Anfragen über einen separaten HTTP-POST-Kanal zurückgeleitet wurden. Dieses asymmetrische Design funktionierte gut für einfaches lokales Tooling, erzwang aber eine dauerhafte Verbindung, die horizontales Skalieren hinter einem Load Balancer unzuverlässig machte; aufeinanderfolgende Anfragen derselben logischen Sitzung konnten auf unterschiedlichen Backend-Instanzen landen und die Kontinuität stillschweigend brechen. Streamable HTTP löst dies, indem jede Anfrage als unabhängig behandelt wird, sofern keine Sitzung explizit ausgehandelt wird — ein Design, das sich direkt auf zustandslose Container-Laufzeiten abbildet und es einem Load Balancer erlaubt, jede Anfrage zu routen, ohne Sticky Sessions als Standardannahme zu benötigen.

Warum es zählt

• Der alte, rein SSE-basierte Transport erforderte eine dauerhafte Verbindung, sodass unterschiedliche Anfragezyklen auf unterschiedlichen Backend-Instanzen landen und Sitzungen brechen konnten — ein echtes Hindernis für horizontales Skalieren.
• Streamable HTTP erlaubt es demselben MCP-Server, auf BTP Cloud Foundry oder Kyma autozuskalieren, TLS am Edge zu terminieren und mit OAuth-2.1-Bearer-Tokens zu authentifizieren.
• Pro-Mandant-Audit-Logs aus jedem Tool-Aufruf können in den SAP AI Agent Hub einfließen und die Dokumentationspflichten aus Art. 9 des EU AI Act bereits auf der Transportschicht erfüllen.

Kernpunkte

• Streamable-HTTP-Transport — MCP-Spezifikationsrevision 2025-03, ersetzt den ursprünglichen reinen SSE-Transport; ein POST-/mcp-Endpunkt, optionales Upgrade auf Chunked-SSE für streamende Antworten.
• Standardmäßig zustandslos — horizontales Skalieren auf BTP Cloud Foundry / Kyma; optionaler Mcp-Session-Id-Header für zustandsbehaftete Sitzungen bei Bedarf.
• OAuth 2.1 verpflichtend, sofern Autorisierung unterstützt wird — die MCP-Spezifikation 2026-07-28 verlangt es bedingt für HTTP-Transporte (Autorisierung selbst bleibt auf Protokollebene optional; siehe C226); die meisten Produktivdeployments benötigen es dennoch.
• Multi-Tenant-fähig — Pro-Mandant-Audit-Logs fließen in den SAP AI Agent Hub (C211); Dokumentationspflichten aus Art. 9-49 EU AI Act werden bereits auf der Transportschicht erfüllt.
• Anti-Pattern — einen reinen stdio-Server ausliefern und ihn dann für die Produktion neu schreiben; HTTP von Tag eins an bauen, wenn mehr als ein Operator ihn nutzen wird.
• Tasks-Erweiterung (Spezifikation 2026-07-28) — bei lange laufenden Tool-Aufrufen kann ein Server statt die HTTP-Verbindung offenzuhalten eine dauerhafte taskId zurückgeben; der Client fragt tasks/get ab oder abonniert Benachrichtigungen und übersteht so Verbindungsabbrüche und Load-Balancer-Timeouts, die ein offengehaltener Stream nicht übersteht.
• Tasks vs. rohes Streaming — eine gechunkte SSE-Antwort bleibt die richtige Wahl für einen Aufruf, der in Sekunden mit inkrementeller Ausgabe fertig ist; Tasks ist die richtige Wahl, wenn der Aufruf Minuten bis Stunden dauern kann oder der Client mittendrin die Verbindung verlieren könnte.

Begriffe auf dieser Seite

Streamable HTTP

MCP-Transport, eingeführt 2025-03 — einzelner HTTPS-POST-Endpunkt, optionales Upgrade auf Chunked text/event-stream für Teilergebnisse; produktives Wire-Format.

Mcp-Session-Id

Optionaler, bei initialize ausgehandelter HTTP-Header für zustandsbehaftete Sitzungen über mehrere Anfragen hinweg; für zustandslose Tool-Aufrufe nicht erforderlich.

OAuth 2.1

Auth-Profil, das MCP verlangt, sobald ein Server sich für Autorisierung bei HTTP-Transporten entscheidet (Spezifikation 2026-07-28); konsolidiert OAuth-2.0-Best-Practices und streicht die Implicit- und ROPC-Flows. Autorisierung selbst bleibt auf Protokollebene optional — siehe C226.

Mandantenbezogener Scope

OAuth-Claim, der den Zugriff eines Tokens auf die MCP-Tools und Datenbereiche eines einzelnen Kundenmandanten einschränkt; Grundlage der Multi-Tenant-Isolation.

MCP-Tasks-Erweiterung

Eine optionale Erweiterung (Spezifikation 2026-07-28, Repository ext-tasks), die es einem Server erlaubt, statt die HTTP-Verbindung für einen lange laufenden Aufruf offenzuhalten, ein dauerhaftes Task-Handle zurückzugeben; der Client fragt tasks/get ab oder abonniert notifications/tasks, bis der Task einen Endzustand erreicht.

CreateTaskResult / taskId

Die Antwort, die ein Tasks-fähiger Server anstelle eines synchronen Ergebnisses liefert: eine taskId, ein Anfangsstatus, eine Time-to-Live (ttlMs) und ein vorgeschlagenes pollIntervalMs. Der Task muss dauerhaft angelegt sein, bevor die Antwort gesendet wird, damit die taskId einen Verbindungsabbruch des Clients übersteht.

input_required (Task-Status)

Ein Lebenszyklus-Zustand der Tasks-Erweiterung, der anzeigt, dass der Server eine Eingabe des Clients benötigt — oft eine Elicitation — bevor er fortfährt; der Client liest die inputRequests-Map aus tasks/get und antwortet über tasks/update, ohne eine zweite Verbindung zu benötigen.

Quellen

1. Model Context Protocol specification — Streamable HTTP transport (2025-03 revision)
2. Model Context Protocol specification — Authorization (2025-06 revision, OAuth 2.1)
3. Anthropic — Model Context Protocol SDK (TypeScript) HTTP transport reference
4. SAP BTP — Cloud Foundry deployment of HTTPS endpoints
5. Model Context Protocol — Tasks extension overview (spec 2026-07-28)
6. Model Context Protocol — ext-tasks specification repository
7. Model Context Protocol — Streamable HTTP transport (spec 2026-07-28)
8. Model Context Protocol — stdio transport (spec 2026-07-28)
9. Model Context Protocol — Extensions overview and client-matrix
10. Model Context Protocol — Transports Working Group
11. Model Context Protocol — Authorization specification (spec 2026-07-28)
12. modelcontextprotocol/typescript-sdk — v2.3.0 release notes, 2 October 2026 (one server per request, same-origin redirects, expectedResource, Tasks on 2026-07-28)
13. modelcontextprotocol/typescript-sdk — v2.3.1 release notes, 5 October 2026 (expectedResource in server-legacy)
14. modelcontextprotocol/python-sdk — v2.3.0 release notes, 2 October 2026 (max_sse_event_size on the Streamable HTTP client)
15. Model Context Protocol — Key changes, specification 2026-07-28 (sessions and SSE resumability removed from Streamable HTTP)