MCP-stdio-Transport — für Claude Desktop, Claude Code, lokale Agenten

Worum es geht

Der MCP-stdio-Transport verbindet einen Model-Context-Protocol-Server mit einem Client — Claude Desktop, Claude Code oder ein lokales Agent-Skript —, indem er zeilenweise getrennte JSON-RPC-2.0-Nachrichten über die Standard-Eingabe und Standard-Ausgabe des Prozesses leitet. Der Client startet den Server als Kindprozess; der Server liest Anfragen von stdin, schreibt Antworten nach stdout und sendet jede Log-Zeile oder Debug-Meldung ausschließlich an stderr. Diese Grenze ist keine Stilfrage, sie ist tragend: Eine einzige versehentliche Print-Anweisung oder Konsolenausgabe, die auf stdout landet, beschädigt den JSON-RPC-Frame und lässt die Sitzung hängen oder komplett abstürzen. Die erste Verteidigungslinie jedes Server-Autors besteht darin, sämtliche Diagnoseausgaben von der allerersten Codezeile an nach stderr zu leiten.

Warum es zählt

• Claude Desktop und Claude Code greifen beide standardmäßig auf stdio zurück, weil das Betriebssystem die Prozessisolation übernimmt und die Authentifizierung implizit ist — keinerlei Netzwerkkonfiguration zu verwalten.
• Nur dann zu HTTP wechseln, wenn der Server über Clients/Maschinen hinweg geteilt werden muss, zustandsbehaftet unabhängig von einem Client ist, einen Container ohne Kindprozess-Start als Ziel hat, oder fein granulares TLS-/Bearer-Auth benötigt.
• Ein häufiger Fehler ist es, für die persönliche Agenten-Werkzeugkiste standardmäßig auf HTTP zu setzen, um „produktiv zu wirken“, und dabei die Einfachheit von stdio ohne Grund zu verlieren.

Kernpunkte

• stdio-Transport — der Host startet den Server als Kindprozess; JSON-RPC-2.0-Nachrichten zeilenweise getrennt über stdin/stdout.
• Vertrauensmodell — die Prozessgrenze des Betriebssystems ist die Sicherheitsgrenze; der Host, der den Server startet, wird vom Nutzer als vertrauenswürdig eingestuft.
• Anwendungsfälle — Claude Desktop, Claude Code, Cursor, Continue, jeder lokale IDE-Agent; der Produktivitätskreislauf eines einzelnen Entwicklers.
• Logging-Disziplin — ausschließlich stderr; Schreiben nach stdout beschädigt den JSON-RPC-Stream und trennt den Host.
• Konstruktionsbedingt Single-Client — zu Streamable HTTP (C227) migrieren, sobald mehr als ein Operator den Server nutzen muss.
• Keine OAuth-Schicht, per Spezifikationsdesign (Spezifikation 2026-07-28) — stdio-Implementierungen SOLLTEN dem HTTP-Autorisierungsmodell gar nicht erst folgen; Zugangsdaten kommen aus der Umgebung (dem env-Block von mcpServers), nicht aus einem Token-Fluss.
• Erweiterungen sind transportunabhängig — Elicitation und die Tasks-Erweiterung (C225, C227) funktionieren über stdio genauso wie über Streamable HTTP; ein lokaler Server kann einen Aufruf weiterhin unterbrechen, um den Nutzer etwas zu fragen, oder für einen langsamen lokalen Job eine dauerhafte taskId zurückgeben.

Begriffe auf dieser Seite

stdio transport

MCP-Wire-Format, bei dem der Host den Server als Kindprozess startet und JSON-RPC-2.0-Nachrichten über dessen stdin/stdout austauscht; der einfachste Deployment-Modus.

claude_desktop_config.json

Pro-Nutzer-JSON-Konfigurationsdatei, in der Claude Desktop MCP-Server registriert; listet Kommando + Argumente + Umgebungsvariablen für jeden Server.

JSON-RPC 2.0

Leichtgewichtiges Remote-Procedure-Call-Protokoll über JSON; die Wire-Kodierung für jede MCP-Nachricht, unabhängig vom Transport.

Single-Client-Beschränkung

Architektureigenschaft von stdio: Ein Host-Prozess besitzt die I/O-Streams des Servers; ein zweiter Client benötigt den HTTP-Transport.

stdio und Autorisierung (Spezifikation 2026-07-28)

Die aktuelle Spezifikation stellt ausdrücklich fest, dass Implementierungen mit stdio-Transport der HTTP-Autorisierungsspezifikation NICHT folgen SOLLTEN und stattdessen Zugangsdaten aus der Umgebung beziehen sollten — sie formalisiert damit, was diese Karte bereits als Vertrauensmodell behandelt.

Elicitation über stdio

Die Client-Funktion (Spezifikation 2026-07-28, siehe C225), mit der ein Server eine Aufgabe mittendrin pausieren kann, um eine weitere Angabe des Nutzers anzufordern; sie ist transportunabhängig, sodass ein stdio-Server sie genauso nutzen kann wie ein HTTP-Server, sofern der Host die Unterstützung bei initialize deklariert.

Erweiterungsaushandlung

Der allgemeine MCP-Mechanismus (Spezifikation 2026-07-28), mit dem Client und Server jeweils bei initialize / server/discover deklarieren, welche optionalen Erweiterungen (Tasks, Elicitation-nahe Funktionen, Skills) sie unterstützen; gilt identisch, unabhängig davon, ob darunter stdio oder Streamable HTTP liegt.

Quellen

1. Model Context Protocol specification — stdio transport
2. Anthropic — MCP TypeScript SDK + stdio examples
3. Anthropic — Claude Desktop MCP configuration reference
4. Model Context Protocol — stdio transport specification (2026-07-28)
5. Model Context Protocol — Authorization specification (2026-07-28), stdio exemption
6. Model Context Protocol — Tasks extension overview (spec 2026-07-28)
7. Model Context Protocol — Extensions client-matrix (host support tracker)
8. Model Context Protocol — Build a server, develop guide (spec 2026-07-28)
9. Model Context Protocol — Security Best Practices tutorial (spec 2026-07-28)
10. Model Context Protocol — Specification versioning documentation (2026-07-28)
11. Model Context Protocol — Local Server Security (stdio trust model, isolation, credentials and egress)
12. Model Context Protocol — Debugging (stdio logging, Claude Desktop logs and common issues)
13. Model Context Protocol — Connect to local MCP servers (Claude Desktop configuration and approval flow)
14. AWS Machine Learning Blog — Add secure Web Search to Claude Desktop with Amazon Bedrock AgentCore (remote managed MCP server with JWT auth, 2 Oct 2026)
15. Google Cloud Blog — Empower your agents with the Google Cloud CLI remote MCP server (CLI behind remote MCP instead of local binaries, 1 Oct 2026)
16. NVIDIA Technical Blog — Add Runtime Controls to AI Agents with NVIDIA OpenShell (runtime permission enforcement outside the agent, 28 Sep 2026)