Stdio vs. Streamable HTTP für MCP: Was sich ändert, wenn man von der lokalen Entwicklung zur Unternehmensbereitstellung übergeht

Stdio ist für den Entwickler-Laptop ausreichend. Streamable HTTP ist das, was Unternehmensbereitstellungen tatsächlich benötigen. Wir gehen beide Transportwege durch – Drahtformat, Verbindungslebenszyklus, Authentifizierung, Audit und Benchmarks – und zeigen, was sich ändert, wenn eine MCP-Umgebung über einen Benutzer hinaus skaliert.

Ein Freitagnachmittag bei Northwind. Sechs Monate nach der Einführung von Cargo Copilot fragt der Sicherheitsverantwortliche von Northwind das Entwicklungsteam eine routinemäßige Audit-Frage: Welche Entwickler haben in den letzten 30 Tagen das interne MCP-Tool für Kundendaten aufgerufen und mit welchen Kunden-IDs? Das Team hat jede JSON-RPC-Nachricht, die jemals diese Tools durchlaufen hat – in den stderr-Logs jedes lokalen Cursor-Prozesses der Entwickler. Verteilt auf fünfzig Laptops. Ohne gemeinsame Zeitstempelquelle, ohne Schema und ohne Möglichkeit zur Korrelation. Die Beantwortung der Frage dauert eine Woche, und die Antwort ist unvollständig. Die Ursache ist nicht Fahrlässigkeit. Es ist die Transportwahl, die sie vor sechs Monaten getroffen haben.

Northwind begann dort, wo die meisten Teams beginnen: mit stdio-MCP-Servern, einen pro Entwicklerrechner. Das ist der richtige Standard für lokale Experimente – und der falsche Standard für alles andere. Dieser Beitrag erklärt, warum, mit den Besonderheiten der Drahtformate, den Bereitstellungsmodellen und dem Migrationspfad.

1. Stdio-Transport: Wie JSON-RPC 2.0 über stdin/stdout funktioniert

Die MCP-Transportspezifikation definiert stdio in einem Absatz: Der Client startet den Server als Unterprozess; der Server liest JSON-RPC 2.0 Nachrichten von stdin und schreibt Antworten nach stdout. Jede Nachricht ist eine Zeile UTF-8-Text, die mit einem Zeilenumbruch endet. Der Server darf Logs nach stderr schreiben; er DARF NICHTS nach stdout schreiben, was keine gültige MCP-Nachricht ist.

Ein einzelner Tool-Aufruf vom Agenten zum Server ist eine Zeile JSON:

Wire format — newline-delimited JSON-RPC over stdio
# stdin (client → server)
{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"search_issues","arguments":{"query":"is:open label:critical"}}}

# stdout (server → client)
{"jsonrpc":"2.0","id":1,"result":{"content":[{"type":"text","text":"Found 3 issues..."}]}}

Die Framing-Regeln sind einfach, aber unerbittlich. Die MCP-Spezifikation verlangt, dass Nachrichten in einer einzigen Zeile stehen, daher escapen konforme Server interne Zeilenumbruchzeichen als \n während der JSON-Serialisierung. Was das Framing in der Produktion tatsächlich unterbricht, ist die Nicht-JSON-Kontamination von stdout: eine verirrte print()-Anweisung, ein nicht abgefangener Exception-Traceback, ein Debug-Log, das versehentlich nach stdout statt stderr geleitet wurde, oder ein Server, der vergisst, stdout nach jeder Nachricht zu leeren. In all diesen Fällen sieht der Client entweder eine fehlerhafte Nachricht oder wartet ewig auf eine Antwort, die technisch geschrieben wurde. Jedes MCP SDK wird mit einer stdio-Transportimplementierung ausgeliefert, gerade um diese Grenzfälle zum Problem eines anderen zu machen.

Was stdio Ihnen im Austausch für diese Einschränkungen bietet, ist Prozessisolation. Der Agent besitzt den Lebenszyklus des Servers: Wenn der Agent beendet wird, fordert das Betriebssystem den Prozess zurück. Es gibt kein Netzwerk, keinen Authentifizierungs-Handshake, keine Firewall-Frage. Für die lokale Entwicklung ist dies genau das, was Sie wollen.

2. Streamable HTTP-Transport: Request-Response- und SSE-Modi

Streamable HTTP, eingeführt in der MCP-Spezifikation 2025-03-26 und in der Revision vom November 2025 beibehalten, ersetzt den älteren HTTP+SSE-Transport durch ein Single-Endpoint-Design. Der Server stellt eine URL bereit (z.B. /mcp), der sowohl POST und GET. Clients senden JSON-RPC-Nachrichten per POST; Server antworten entweder mit einem einzelnen JSON-Body oder wechseln zu einem Server-Sent Events-Stream für langlaufende Aufrufe. Es gibt keinen separaten „Events“-Endpunkt.

Der Client signalisiert, was er akzeptieren kann; der Server wählt den Antwortmodus. Hier ist ein Tool-Aufruf in HTTP-Form:

Wire format — Streamable HTTP, both response modes
POST /mcp HTTP/1.1
Content-Type: application/json
Accept: application/json, text/event-stream
Mcp-Session-Id: 1d3f...e7c2
Authorization: Bearer eyJhbGciOi...

{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"search_issues",...}}

# --- Server response: short call returns plain JSON ---
HTTP/1.1 200 OK
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"result":{"content":[...]}}

# --- Server response: long call upgrades to SSE ---
HTTP/1.1 200 OK
Content-Type: text/event-stream

event: message
data: {"jsonrpc":"2.0","method":"notifications/progress","params":{...}}

event: message
data: {"jsonrpc":"2.0","id":1,"result":{"content":[...]}}

Drei Details sind im Betrieb wichtig. Der Mcp-Session-Id -Header bindet Anfragen an eine Sitzung und wird vom Server bei der Initialisierung zugewiesen – er bleibt über Pod-Neustarts hinweg nur erhalten, wenn der Server den Sitzungsstatus externalisiert. Der Accept -Header ist obligatorisch: Gemäß Spezifikation MÜSSEN Clients MÜSSEN sowohl application/json als auch text/event-streamauflisten, und ein konformer Server kann einen fehlenden oder unvollständigen Accept mit HTTP 406 Not Acceptable (gemäß HTTP-Semantik; 415 Unsupported Media Type gilt für inkompatible Content-Type, nicht Accept). Und gemäß dem Sicherheitsabschnitt der Spezifikation, müssen Server Zwingend den Origin -Header bei jeder Verbindung validieren, um DNS-Rebinding-Angriffe auf lokal gebundene Server zu verhindern – eine normative Anforderung, keine Empfehlung, mit HTTP 403 Forbidden als vorgeschriebene Antwort auf einen ungültigen Origin.

3. Verbindungslebenszyklus: Prozess pro Benutzer vs. zustandsloses HTTP

Die beiden Transportprotokolle modellieren Verbindungen völlig unterschiedlich, und hier entsteht die operative Lücke.

Für einen einzelnen Entwickler, der lokal arbeitet, ist das Prozess-pro-Verbindung-Modell von stdio ein Feature, kein Bug – Prozessisolation ist kostenlos, und der Kaltstart erfolgt einmalig beim Öffnen der IDE. Sobald mehr als ein Benutzer den Server benötigt, wird dieses Modell zur Einschränkung.

4. Mandantenfähigkeit: Warum Stdio bei Skalierung an seine Grenzen stößt

Die stdio-Einschränkung, die im Unternehmensbereich zum Problem wird, ist eher arithmetischer als technischer Natur: Typische stdio MCP-Bereitstellungen führen einen Prozess pro (Benutzer, Server)-Tupel aus, ohne integrierte gemeinsame Nutzung über Benutzer hinweg. Einige Implementierungen multiplexen mehrere Tool-Definitionen innerhalb eines Unterprozesses, und einige wenige poolen Unterprozesse, aber das gängige Bereitstellungsmuster in der Praxis – und dasjenige, das in den offiziellen SDKs ausgeliefert wird – ist ein Prozess pro Benutzer pro Server.

Bei Northwind betreiben 50 Entwickler jeweils eine IDE mit acht angeschlossenen MCP-Servern. Das sind 400 Stdio-Prozesse während der Spitzenzeiten, verteilt auf 50 Laptops. Jeder Prozess belegt Speicher (ein Python-MCP-Server mit wenigen Abhängigkeiten benötigt etwa 60–120 MB residenten Speicher; ein Node-Server ist ähnlich), hält Dateideskriptoren offen und unterhält eine aktive Laufzeitumgebung, die auf stdin blockiert ist. Der gesamte Ressourcenverbrauch ist nicht katastrophal – 400 kleine Prozesse liegen gut im Rahmen der Möglichkeiten moderner Hardware – doch die wahren Kosten sind eher operativer als rechnerischer Natur: Die Anzahl der Prozesse fragmentiert die Steuerungsebene.

Das schwierigere Problem sind Shared-State-Server. Stellen Sie sich vor, der interne Logistics API MCP-Server speichert beim Start einen 200 MB großen Kundengraphen im Speicher. Bei Stdio lädt jede Entwicklermaschine ihre eigene Kopie. Bei Streamable HTTP halten zwei Pod-Replikate den Graphen für das gesamte Unternehmen. Dieselben Daten, aggregiert zwei Größenordnungen weniger Speicher, plus der Cache ist über alle Benutzer hinweg warm, weil er geteilt wird.

Es lohnt sich, die andere Seite der Medaille zu beleuchten. Das dezentrale Modell von Stdio hat echte Vorteile, die ein erfahrenes Infrastrukturteam zu Recht anführen wird: starke Fehlerisolation (der abgestürzte Server eines Entwicklers betrifft niemanden sonst), keine gemeinsame Ingress-Abhängigkeit, kein zentraler Authentifizierungsausfall, der das gesamte System lahmlegt, und minimale Infrastruktur zum Betrieb. Für kleine Teams, hochgradig vertrauenswürdige lokale Workflows oder luftdicht abgeschirmte Umgebungen können diese Eigenschaften die operativen Vorteile einer zentralisierten HTTP-Ebene tatsächlich überwiegen. Das Argument in diesem Beitrag ist nicht, dass Stdio schlecht ist; es ist vielmehr, dass die Fehlermodi, die es der Organisation aufzwingt – fragmentierte Audits, verteilte Anmeldeinformationen, keine zentrale Ratenbegrenzung – genau dann auftreten, wenn ein System von "einigen wenigen Power-Usern" zu "gemeinsamer Infrastruktur mit Compliance-Verpflichtungen" übergeht.

‍

‍