MCP · Lektion 04 · Transports

STDIO vs. Streamable HTTP

Die JSON-RPC-Nachrichten aus Lektion 2 müssen ja irgendwie transportiert werden. MCP definiert dafür genau zwei Standard-Wege. Die Wahl bestimmt, wo dein Server läuft und wie du ihn deployst.

1. STDIO — der Server ist ein Subprozess

Beim stdio-Transport startet der Client den Server als Kindprozess. Kommunikation läuft über die Standard-Streams:¹

• Client schreibt JSON-RPC nach stdin des Servers.
• Server antwortet über stdout.
• Nachrichten sind newline-delimited und dürfen keine eingebetteten Newlines enthalten.
• stderr ist für Logging frei — aber auf stdout darf nichts stehen, was keine gültige MCP-Nachricht ist (ein print() zerstört dir sonst die Verbindung!).

Wann? Lokale Integrationen: Server und Agent laufen auf derselben Maschine. Genau so läuft dein forgejo-Server in Claude Code. Die Spec sagt: Clients SHOULD stdio unterstützen, wann immer möglich.¹ Es ist der einfachste Weg — kein Port, kein Netzwerk, keine Auth.

2. Streamable HTTP — ein eigenständiger Dienst

Beim Streamable HTTP-Transport läuft der Server als unabhängiger Prozess, der mehrere Clients bedienen kann. Ein einziger Endpunkt (z.B. https://example.com/mcp) nimmt:¹

• POST für jede Client-Nachricht. Antwort ist entweder eine einzelne JSON-Antwort oder ein SSE-Stream (Server-Sent Events), wenn der Server streamen will.
• GET, um einen SSE-Stream zu öffnen, über den der Server von sich aus Nachrichten schicken kann.
• Optionale Sessions via Mcp-Session-Id-Header, der bei initialize vergeben und danach mitgeschickt wird.

Wann? Remote: ein zentral gehosteter Server, an den sich viele Nutzer/Agents übers Netz verbinden. Das ist der empfohlene Transport für Production-Deployments.²

Sicherheits-Warnung der Spec für HTTP: den Origin-Header validieren (DNS-Rebinding!), lokal nur an 127.0.0.1 binden statt 0.0.0.0, und Auth einbauen.¹

Historische Notiz fürs Workshop-Selbstbewusstsein: „Streamable HTTP“ ersetzte ab Spec 2025-03-26 den älteren „HTTP+SSE“-Transport. Wenn du irgendwo noch von zwei getrennten SSE-/POST-Endpunkten liest — das ist die alte Variante.¹

3. Im Python-SDK: ein Argument

Die gute Nachricht für deinen Bau in Lektion 5: das SDK kapselt beide Transports. Du schreibst dein Tool einmal und wählst beim Start:

if __name__ == "__main__":
    mcp.run(transport="stdio")            # lokal, an Claude Code/Duo
    # mcp.run(transport="streamable-http") # remote, als Webdienst

Mehr ist es nicht. Derselbe Server, zwei Türen.²

4. Mini-Check (aus dem Kopf!)

Warum killt ein print("debug") einen STDIO-Server?

stdout darf nur MCP-Nachrichten enthalten print ist in Python generell verboten stdin akzeptiert keine zweite Zeile

Ein zentral gehosteter Server für viele Nutzer — welcher Transport?

STDIO, weil simpler ohne Ports Streamable HTTP, ein Netz-Endpunkt Beide gleichzeitig zwingend nötig

Wer startet bei STDIO den Server-Prozess?

Der Client startet ihn als Subprozess Der Server startet sich selbst beim Boot Ein systemd-Dienst im Hintergrund immer

5. Primärquelle

📖 MCP Specification — Transports. Lies stdio und Streamable HTTP inkl. der Security-Warnung.

Sag „weiter“ für Lektion 5 — jetzt bauen wir endlich: dein erster Python-MCP-Server mit dem offiziellen SDK, getestet im MCP Inspector.

1 — MCP Specification, Transports (2025-06-18): …/basic/transports

2 — Python SDK README (modelcontextprotocol/python-sdk): github.com/modelcontextprotocol/python-sdk

← Lektion 03 · Primitive Kursübersicht Lektion 05 · Bauen →