Describe how stdio transport works in MCP, when it is the right choice, and name at least one scenario where it would be the wrong choice.
Free · 2 AI evals / day
**stdio transport** is the simplest way an MCP host talks to a server. The host launches the server program as a child process on the same machine. Then the two exchange messages through that process's standard input and standard output.
Each message is a JSON-RPC request or response written as one line, ending in a newline. The host writes a request to the server's stdin; the server writes its reply to stdout. Anything the server logs goes to stderr, kept separate so it never corrupts the message stream.
Use stdio when the server runs locally and you trust it: a filesystem server, a Git server, a local database helper. There is no network, no port, no TLS, and no login. That makes it both simple and naturally private.
The catch is that stdio cannot cross a network. A host on your laptop cannot spawn a process on a server in the cloud. For anything remote, MCP uses an HTTP-based transport instead.
stdio is MCP's local transport. The host launches the server as a child subprocess and speaks JSON-RPC over the process's stdin and stdout.
Every message is newline-delimited. One JSON object per line, so the reader knows where each message ends. Requests flow into the server's stdin. Responses come back on stdout. The server's own logs go to stderr, which keeps diagnostic noise out of the protocol channel.
The right fit is local, trusted tooling. A filesystem server, a Git server, or a Postgres helper running on the developer's own machine. There is no network listener, so you skip authentication, TLS, and port management. That makes stdio both the simplest transport and the most contained one.
The wrong fit is anything remote. stdio has no socket and no port, so a host on one machine cannot reach a server on another. A cloud VM or a serverless function cannot accept a stdio connection from across the network. For those cases you reach for Streamable HTTP, the current remote transport.
One security caveat matters. The subprocess inherits the host's privileges and environment, so a malicious local server runs with your access.
Quick reference
TL;DR
stdio launches the MCP server as a local subprocess and pipes newline-delimited JSON-RPC over stdin and stdout; perfect for local trusted tools, useless across a network.
Imagine two people in the same room passing notes back and forth. The host writes a note (a request) and hands it through one slot; the server writes its reply and hands it back through another slot. That's stdio: the host starts the server program right next to it, then they exchange messages by writing lines of text. Each note is one line, so the reader knows a note ends at the newline. Because the two are in the same room, there's no mail carrier, no address, no lock on the door. Simple and private. But if the server lives in another building, you cannot pass notes by hand anymore. Then you need the postal system, which is the network transport.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Server deployed on a remote VM or serverless function stdio has no network listener, so a client on another machine simply cannot establish a connection to it.
One server must serve many simultaneous clients stdio binds one server process to a single client over its pipes, so it cannot fan out to concurrent connections.
Untrusted third-party server you cannot vet The subprocess inherits your privileges and environment, so a malicious local server runs with full access to your machine.
Quick scan · 2–4 min
Everything important, quickly.
4 min: subprocess model + stdin, stdout, stderr roles + newline-delimited JSON-RPC framing + local trust use cases + privilege caveat + why remote needs Streamable HTTP.
Side-by-side
Concern
stdio transport
Streamable HTTP transport
Topology
Local subprocess, same machine
Remote server across a network
Channel
stdin and stdout pipes
HTTP requests, optional streaming
Auth needed
None, no network surface
Yes, OAuth 2.1 bearer tokens
Multi-client
One client per process
Many clients to one server
Best for
Local trusted dev tools
Cloud and shared deployments
Real-world examples
Real products, models, and research that use this idea.
1Claude Desktop and Claude Code spawn local stdio servers from a config file entry, such as the official filesystem and Git servers.
2The official MCP filesystem and Postgres reference servers ship as stdio-by-default subprocesses launched via npx or uvx.
3Cursor and Zed register local stdio MCP servers per project, piping JSON-RPC over the spawned process's stdin and stdout.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does the host frame and parse stdio messages reliably when output can arrive in fragments?
Sign in or go Pro to see the approach for this follow-up.
QWhat is the threat model for a local stdio server, and how do you contain it?
Sign in or go Pro to see the approach for this follow-up.
QWhy was HTTP plus SSE deprecated, and what does Streamable HTTP change for remote MCP?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Thinking stdio can reach a remote server. It has no listener and no port, so it only works when host and server share one machine.