Streamable HTTP: Echtzeit-KI-Interaktion via MCP revolutioniert
Das Model Context Protocol (MCP) ist ein offener Standard, der entwickelt wurde, um künstliche Intelligenzmodelle – die als Clients fungieren – nahtlos mit externen Tools und verschiedenen Datenquellen, die als Server fungieren, zu verbinden. Während lokale Integrationen einen einfachen Standard-Ein-/Ausgabemechanismus nutzen können, basieren Remote-Interaktionen über Netzwerke auf einer ausgeklügelten HTTP-basierten Kommunikationsschicht. Hier kommt Streamable HTTP ins Spiel, ein moderner Transportmechanismus, der Anfang 2025 als Weiterentwicklung früherer Ansätze eingeführt wurde und speziell für die Verwaltung von Streaming-Interaktionen zwischen KI-Clients und ihren Remote-Tools entwickelt wurde. Im Wesentlichen ermöglicht Streamable HTTP dem MCP, Daten über das Internet in einem kontinuierlichen Echtzeitfluss zu übertragen und zu empfangen, jenseits des traditionellen Einzelanfrage-Antwort-Paradigmas. Diese Innovation ist grundlegend für die Funktionsweise entfernter MCP-Server und ermöglicht es KI-Agenten, flüssig und hochgradig interaktiv mit Webdiensten zu interagieren.
Im Kern ist Streamable HTTP ein HTTP-basiertes Kommunikationsframework, das Streaming-Antworten und bidirektionale Kommunikation über eine einzige HTTP-Verbindung ermöglicht. Aus Sicht des Clients beinhaltet dies typischerweise das Senden von Anfragen über HTTP POST. Der Server kann seinerseits entweder mit einer herkömmlichen einzelnen JSON-Nachricht antworten oder einen Live-Ereignisstrom mithilfe von Server-Sent Events (SSE) initiieren, um mehrere Nachrichten im Laufe der Zeit zu liefern. Ein wichtiges Designmerkmal ist die Verwendung eines einzigen, vereinheitlichten HTTP-Endpunkts durch den Server – zum Beispiel https://example.com/mcp –, der sowohl POST-Anfragen zum Senden von Befehlen als auch GET-Anfragen zum Aufbau eines persistenten Listening-Streams aufnimmt. Diese Single-Endpoint-Architektur vereinfacht die Implementierung im Vergleich zu älteren, komplexeren Multi-Endpoint-Schemata erheblich. Entscheidend ist, dass Streamable HTTP die Kompatibilität mit bestehender Web-Infrastruktur wie Proxys und Lastverteilern aufrechterhält, indem es auf Standard-HTTP-Protokollen (POST, GET) und SSE aufbaut und gleichzeitig langlebige Datenströme ermöglicht. Im Wesentlichen bietet es einen kontrollierten Mechanismus für MCP, Daten über HTTP zu streamen, wobei SSE verwendet wird, um bei Bedarf kontinuierliche Servernachrichten zu liefern.
Um die Mechanik von Streamable HTTP vollständig zu erfassen, ist es hilfreich, die sequenziellen Schritte einer typischen Client-Server-Interaktion vom anfänglichen Setup bis zur Beendigung zu verfolgen. Der Prozess beginnt damit, dass der Client eine Sitzung initiiert, indem er eine HTTP POST-Anfrage an den designierten MCP-Endpunkt des Servers sendet. Diese grundlegende Anfrage enthält Informationen über die Fähigkeiten des Clients und die gewünschte Protokollversion. Nach erfolgreicher Verarbeitung antwortet der Server mit einem HTTP 200 OK-Status, der entscheidend eine eindeutige Mcp-Session-Id in seinen Headern enthält. Dieser Bezeichner ist der Eckpfeiler für die Aufrechterhaltung des Sitzungszustands, und der Client muss ihn in allen nachfolgenden Anfragen einschließen, um den Kontext zu erhalten. Der Antwortkörper bestätigt auch die erfolgreiche Einrichtung und detailliert die Fähigkeiten des Servers, wie z.B. verfügbare Tools.
Nach dem Aufbau der Sitzung öffnet der Client typischerweise einen sekundären Kommunikationskanal für vom Server initiierte Nachrichten, bekannt als Ankündigungskanal. Dies wird erreicht, indem eine HTTP GET-Anfrage an denselben Endpunkt gesendet wird, die wiederum die Mcp-Session-Id enthält und ihre Absicht signalisiert, Ereignisströme über den Accept: text/event-stream-Header zu empfangen. Der Server antwortet mit HTTP 200 OK und einem Content-Type: text/event-stream-Header, wodurch die TCP-Verbindung auf unbestimmte Zeit offen gehalten wird. Diese persistente Verbindung ermöglicht es dem Server, JSON-RPC-Anfragen oder Benachrichtigungen jederzeit an den Client zu pushen, unabhängig von den eigenen Befehlsanfragen des Clients.
Die wahre Leistungsfähigkeit von Streamable HTTP wird bei der Bearbeitung lang laufender Aufgaben, die Echtzeit-Updates erfordern, deutlich. Wenn ein Client eine solche Aufgabe ausführen muss, zum Beispiel ein Datenanalyse-Skript, sendet er eine weitere HTTP POST-Anfrage, die den relevanten Befehl enthält, komplett mit der Mcp-Session-Id. Der Server erkennt dies als potenziell lange Operation und antwortet sofort mit einem HTTP 200 OK-Status und einem Content-Type: text/event-stream-Header. Diese Aktion hält die Verbindung für diese spezifische POST-Anfrage offen und wandelt ihren Antwortkörper in einen dedizierten SSE-Stream um. Während die Aufgabe fortschreitet, sendet der Server Echtzeit-Updates als SSE-Ereignisse auf diesem Stream. Sobald die Aufgabe abgeschlossen ist, wird das Endergebnis als letztes SSE-Ereignis gesendet, und dieser spezifische Stream wird dann geschlossen, wodurch alle Fortschrittsaktualisierungen und das Endergebnis sauber der initiierenden Anfrage zugeordnet werden.
Entscheidend ist, dass die beiden Kanäle unabhängig voneinander arbeiten. Während eine lang laufende POST-Transaktion im Gange ist, kann der Server weiterhin mit dem Client über nicht verwandte Angelegenheiten kommunizieren. Wenn beispielsweise ein neues Tool zum Server hinzugefügt wird, kann er eine Benachrichtigung erstellen und sie als SSE-Ereignis nicht auf dem aktiven POST-Antwortstrom, sondern über die zuvor hergestellte persistente GET-Verbindung senden. Dies demonstriert den Ankündigungskanal in Aktion, der sitzungsbezogene, allgemeine Benachrichtigungen liefert, die von jedem spezifischen, vom Client initiierten Befehl entkoppelt sind.
Das Protokoll ist auch für Robustheit gegenüber Netzwerkfehlern ausgelegt. Wenn die langlebige GET-Verbindung des Clients (der Ankündigungskanal) abbricht, erkennt die Netzwerkbibliothek des Clients die Trennung und sendet sofort eine neue HTTP GET-Anfrage. Diese Anfrage enthält sowohl die Mcp-Session-Id als auch einen Last-Event-ID-Header, der das letzte erfolgreich verarbeitete Ereignis angibt. Der Server verwendet diese Informationen, um alle Nachrichten, die nach diesem Ereignis gesendet wurden und die der Client möglicherweise verpasst hat, erneut abzuspielen, wodurch der Ankündigungskanal nahtlos und ohne Datenverlust wiederhergestellt wird. Dieser geschichtete Ansatz zum Zustand – wobei die Mcp-Session-Id eine dauerhafte Anwendungsschichtsitzung erstellt und offene HTTP-Verbindungen einen kurzlebigen Transportschicht-Stream-Zustand bereitstellen – ermöglicht eine solche Widerstandsfähigkeit, wodurch das Protokoll den kurzlebigen Transportzustand mithilfe des dauerhaften Anwendungszustands bei Unterbrechungen wiederherstellen kann.
Schließlich, wenn der Client alle seine Aufgaben abgeschlossen hat, beendet er die Sitzung explizit, indem er eine HTTP DELETE-Anfrage an den /mcp-Endpunkt sendet, einschließlich der Mcp-Session-Id. Der Server validiert die ID, bereinigt alle zugehörigen Sitzungszustände, schließt die persistente GET-Verbindung und invalidiert die Sitzungs-ID, indem er mit einem HTTP 200 OK antwortet, um den Kommunikationslebenszyklus formell abzuschließen.
Streamable HTTP ist ein Eckpfeiler der Fähigkeit von MCP, KI-Agenten auf reichhaltige, interaktive Weise über das Internet mit Tools zu verbinden. Durch die Erweiterung von HTTP, um Streaming-freundlich zu sein, und die Nutzung von SSE für kontinuierliche Updates bietet es die für KI-Systeme unerlässliche Flexibilität, die Ausgaben streamen, lang laufende Aufgaben verwalten und Echtzeit-Synchronisation aufrechterhalten müssen. Im Gegensatz zum traditionellen HTTP-Anfrage-Antwort-Modell hält Streamable HTTP die Konversation am Leben: Ein KI-Agent kann eine Aufgabe mit einem Tool initiieren und sofort Fortschrittsaktualisierungen oder Ergebnisse empfangen, während das Tool auch Warnungen senden oder auf derselben persistenten Kommunikationsleitung um Klärung bitten kann. Dieser Ansatz verbessert die Zuverlässigkeit durch Sitzungswiederaufnahmefähigkeiten erheblich und steigert die Effizienz, indem unnötige Always-On-Verbindungen vermieden werden, wobei er gleichzeitig vollständig mit etablierten Webstandards kompatibel bleibt. In der Praxis ermöglicht Streamable HTTP Szenarien wie einen Coding-Assistenten, der Live-Logs von einem Remote-Build-Tool streamt, oder einen Datenanalyse-Agenten, der eine Datenbank abfragt und Ergebnisse inkrementell empfängt. Es vereint effektiv die Einfachheit von HTTP mit der Leistungsfähigkeit des Streamings und erfüllt damit das Versprechen von MCP, als „USB-C für KI-Tools“ zu fungieren, indem es eine einheitliche, robuste Schnittstelle für das Streaming von Kontext und Daten zwischen KI und der Welt bereitstellt.