stdio
Also written standard input/output transport
stdio is the MCP transport where a client launches the server as a child process and exchanges JSON-RPC messages over its standard input and output. There is no URL and no network hop. It is the default for local, single-user servers and the most common transport in the ecosystem.
Updated
What is the stdio transport?
stdio is the local transport. Rather than connecting to an address, the client starts the server as a subprocess and talks to it by writing JSON-RPC messages to its standard input and reading replies from its standard output.
A stdio server is usually distributed as a command, most often something a client runs with npx or a similar launcher.
Why is stdio so common?
Because it is the simplest thing that works for a single user on one machine. There is no hosting, no TLS, no authorization, and no uptime to maintain. The server exists only while the client is running it.
It also fits the original use case exactly: giving a desktop assistant access to local files, local git repositories, and local databases, none of which should be reachable over the internet anyway.
How do you run a stdio MCP server?
You do not start it yourself: you tell your client the command, and the client starts it. In Claude Desktop, Cursor and most other clients that is an entry under mcpServers in a JSON config file:
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/you/projects"],
"env": {}
}
}
}
command and args are the process to launch, and env passes it secrets such as API keys without putting them in the arguments. The client launches the process when it starts and stops it when it quits.
One rule breaks more stdio servers than any other: standard output carries protocol messages and nothing else. Each message is one line of JSON-RPC, and a server must not write anything to stdout that is not a valid MCP message [1]. A stray print or a startup banner corrupts the stream and the client drops the connection. Logs go to standard error, which clients are free to capture or ignore.
stdio or Streamable HTTP?
| stdio | Streamable HTTP | |
|---|---|---|
| Who can reach it | Only the client on the same machine | Any client that has the URL |
| Who runs it | Each user, as a local process | The author, as a hosted service |
| Who can check it | Only someone who runs the command | Anyone, by calling the URL |
Pick stdio for a tool that touches one person's machine. Pick HTTP when other people, or a cloud client like ChatGPT, need to reach it: remote MCP servers covers what that costs.
Why can nobody check a stdio server for you?
Because there is nothing to connect to. A stdio server is a command on your machine, so verifying one means running a stranger's command, which is arbitrary code execution rather than a network request.
That asymmetry is structural, not a limitation of any one tool. We record a submitted stdio command and display it so a reader can copy it, and we never execute it. It also means a stdio server carries no connection record here, because we have nothing measured to report and will not invent one.
Example
A typical stdio server is started by a line in a client's configuration rather than by a URL: a command, some arguments, and an environment block. Contrast that with https://mcp.deepwiki.com/mcp, which anyone can point a client at from anywhere. Both are valid MCP servers. Only one of them can be checked by a third party.