Streamable HTTP

Kurz: Einer der Transport-Typen, über die sich ein MCP-Client und -Server unterhalten (neben stdio und dem älteren SSE). Bei Streamable HTTP läuft die Kommunikation über normale HTTP-Requests an einen Endpunkt (typischerweise /mcp).

Genauer: Im Gegensatz zu stdio (wo der Client den Server-Prozess selbst startet, z. B. node server.js) verbindet sich der Client bei Streamable HTTP zu einem bereits laufenden Server über eine URL – gut geeignet, wenn der Server (wie hier das Obsidian-Plugin) ohnehin schon als Teil einer anderen App läuft.

Kontext bei uns: Der Obsidian-MCP-Server läuft unter http://127.0.0.1:27200/mcp als Streamable-HTTP-Endpunkt, den wir per claude mcp add --transport http eingebunden haben.

Im Detail

Ablösung von SSE

Streamable HTTP löste 2025 den älteren SSE-Transport (Server-Sent Events) als empfohlenen MCP-Standard für Netzwerk-Verbindungen ab. Der Kernunterschied: SSE brauchte zwei getrennte Verbindungen (eine für Client-zu-Server-Nachrichten per normalem POST, eine separate dauerhaft offene Verbindung für Server-zu-Client-Nachrichten) — Streamable HTTP bündelt beides über denselben /mcp-Endpunkt, wobei eine einzelne Antwort bei Bedarf trotzdem als Stream (mehrere Nachrichten nacheinander) statt als einzelne komplette Antwort geliefert werden kann. Diese Vereinfachung reduziert auch die Infrastruktur-Komplexität auf Serverseite deutlich: Statt zwei unterschiedliche Verbindungstypen gleichzeitig verwalten zu müssen (inklusive der Frage, wie beide bei einem Verbindungsabbruch synchron gehalten werden), reicht ein einzelner, klassischer HTTP-Endpunkt.

stdio vs. Netzwerk-Transports

Für den stdio-Transport (die Alternative ohne Netzwerk) startet der Client den Server-Prozess selbst als Kindprozess und kommuniziert über dessen Standard-Ein-/Ausgabe — das funktioniert nur, wenn Client und Server auf derselben Maschine laufen. Streamable HTTP wird immer dann nötig, wenn der Server unabhängig vom Client läuft (wie hier das Obsidian-Plugin, das startet, sobald Obsidian selbst läuft, unabhängig davon ob gerade eine Claude-Session aktiv ist) oder wenn Client und Server auf unterschiedlichen Maschinen sitzen sollen. Ein praktischer Vorteil von stdio: Da der Client den Prozess selbst startet und beendet, muss sich niemand um Lifecycle-Management kümmern (der Server läuft nur, solange er gebraucht wird) — bei Netzwerk-Transports wie Streamable HTTP muss der Server dagegen eigenständig laufen und erreichbar bleiben, unabhängig davon, ob gerade ein Client verbunden ist.

Sitzungsverwaltung und Authentifizierung

Da Streamable HTTP über normale HTTP-Requests läuft, lassen sich Standard-Web-Mechanismen direkt wiederverwenden: Sitzungen können über eine Session-ID (z. B. als Header) verwaltet werden, und Authentifizierung läuft über gängige HTTP-Muster wie einen Bearer Token im Authorization-Header — genau wie bei einer klassischen REST-API. Das ist ein praktischer Vorteil gegenüber stdio, wo es naturgemäß keine “Authentifizierung” im klassischen Sinn braucht (der Client hat den Server ja selbst gestartet und läuft im selben Sicherheitskontext), aber dafür auch keinen eingebauten Mechanismus dafür gibt, sollte er doch einmal nötig werden.

Wann welcher Transport sinnvoll ist

Als Faustregel: stdio für Server, die rein lokal und pro Client-Instanz einmalig gestartet werden (z. B. ein Dateisystem-Zugriffs-Tool), Streamable HTTP für Server, die als eigenständiger, dauerhaft laufender Dienst existieren und potenziell von mehreren Clients gleichzeitig oder über Zeit hinweg genutzt werden — wie hier ein Obsidian-Plugin, das unabhängig vom Lebenszyklus einer einzelnen Claude-Code-Session läuft.

Siehe auch: MCP (Model Context Protocol), Bearer Token, HTTP