Der STDIO-Transport

MCP-Clients und -Server kommunizieren durch den Austausch von JSON-Nachrichten, aber wie werden diese Nachrichten tatsächlich übertragen? Der verwendete Kommunikationskanal wird als Transport bezeichnet, und es gibt mehrere Möglichkeiten, diesen zu implementieren – von HTTP-Anfragen über WebSockets bis hin zum Schreiben von JSON auf eine Postkarte (wobei Letzteres für den Produktionseinsatz nicht empfohlen wird).

Wenn du zum ersten Mal einen MCP-Server oder -Client entwickelst, ist der am häufigsten verwendete Transport der Stdio-Transport. Dieser Ansatz ist unkompliziert: Der Client startet den MCP-Server als Subprozess und kommuniziert über die Standard-Eingabe- und -Ausgabeströme.

Diagramm des Stdio-Transports: Ein MCP-Client sendet Nachrichten an einen MCP-Server über die stdin des Servers, und der Server sendet Nachrichten über stdout zurück; jede Seite kann jederzeit eine Nachricht senden, und es funktioniert nur, wenn beide auf derselben Maschine laufen

So funktioniert es:

Der Client sendet Nachrichten an den Server über die stdin des Servers
Der Server antwortet, indem er in stdout schreibt
Sowohl der Server als auch der Client können jederzeit eine Nachricht senden
Funktioniert nur, wenn Client und Server auf derselben Maschine laufen

Stdio in Aktion sehen

Du kannst einen MCP-Server tatsächlich direkt von deinem Terminal aus testen, ohne einen separaten Client zu schreiben. Wenn du einen Server mit uv run server.py ausführst, lauscht er auf stdin und schreibt Antworten auf stdout. Das bedeutet, du kannst JSON-Nachrichten direkt in dein Terminal einfügen und die Antworten des Servers sofort sehen.

Die Terminal-Ausgabe zeigt den vollständigen Nachrichtenaustausch, einschließlich Beispielnachrichten für die Initialisierung und Tool-Aufrufe.

MCP-Verbindungssequenz

Jede MCP-Verbindung muss mit einem bestimmten dreiteiligen Handshake beginnen:

Sequenzdiagramm des MCP-Handshakes: Der Client sendet eine Initialize Request an den Server, der Server antwortet mit einem Initialize Result, dann sendet der Client eine Initialized Notification, auf die kein Ergebnis zurückkommt

Initialize Request – Der Client sendet diese zuerst
Initialize Result – Der Server antwortet mit seinen Fähigkeiten
Initialized Notification – Der Client bestätigt (keine Antwort erwartet)

Erst nach diesem Handshake kannst du andere Anfragen wie Tool-Aufrufe oder Prompt-Auflistungen senden.

Nachrichtentypen und Ablauf

MCP unterstützt verschiedene Nachrichtentypen, die in beide Richtungen fließen:

Diagramm der MCP-Nachrichtentypen zwischen Client und Server: vom Client initiierte Request/Result-Paare wie Call Tool Request → Call Tool Result, vom Server initiierte Paare wie Create Message Request und List Roots Request, sowie einseitige Benachrichtigungen von jeder Seite, die keine Antwort erfordern

Die zentrale Erkenntnis ist, dass manche Nachrichten Antworten erfordern (Requests → Results), während andere dies nicht tun (Notifications). Sowohl Client als auch Server können die Kommunikation jederzeit initiieren.

Vier Kommunikationsszenarien

Bei jedem Transport musst du vier verschiedene Kommunikationsmuster handhaben:

Diagramm mit dem Titel „Wie können wir jedes dieser Muster mit stdio implementieren?", das vier Muster auflistet – erste Anfrage vom Client an den Server, Antwort vom Server an den Client, erste Anfrage vom Server an den Client und Antwort vom Client an den Server – neben einem MCP-Client, der mit der stdin und stdout eines MCP-Servers verbunden ist

Client → Server Request: Der Client schreibt in stdin
Server → Client Response: Der Server schreibt in stdout
Server → Client Request: Der Server schreibt in stdout
Client → Server Response: Der Client schreibt in stdin

Die Schönheit des Stdio-Transports liegt in seiner Einfachheit – jede Partei kann die Kommunikation jederzeit über diese beiden Kanäle initiieren.

Warum das wichtig ist

Das Verständnis des Stdio-Transports ist entscheidend, da er den „idealen" Fall darstellt, in dem bidirektionale Kommunikation nahtlos funktioniert. Wenn wir zu anderen Transporten wie HTTP wechseln, werden wir auf Einschränkungen stoßen, bei denen der Server nicht immer Anfragen an den Client initiieren kann. Der Stdio-Transport dient als unsere Basis, um zu verstehen, wie vollständige MCP-Kommunikation aussieht, bevor wir uns mit den Einschränkungen anderer Transportmethoden befassen.

Für Entwicklung und Tests ist der Stdio-Transport perfekt. Für Produktionsbereitstellungen, bei denen Client und Server auf unterschiedlichen Maschinen laufen müssen, musst du andere Transportoptionen mit ihren eigenen Kompromissen in Betracht ziehen.