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.
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.
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.