stdio Transport
MCPDefinition
An MCP transport mechanism where the client launches the server as a subprocess and communicates via stdin/stdout pipes. Ideal for local development and trusted single-user environments. Simple to set up but limited to same-machine deployment.
Example Usage
Configure a local database MCP server using stdio transport in .mcp.json for development environments.
Why It Matters for the CCA-F Exam
CCA-F questions frequently present deployment scenarios and ask which transport to use. The canonical rule is: stdio for local/trusted/single-user, StreamableHTTP for remote/multi-user/production. Expect questions that describe a shared internal tools server and ask why stdio would be inappropriate — the answer is always multi-client support.
In Depth
The stdio transport is the simpler of the two official Model Context Protocol (MCP) transport mechanisms. When using stdio, the MCP client spawns the server as a child process and communicates with it over the process's standard input and standard output streams. All JSON-RPC messages are written to stdin of the server process and read from its stdout; the server's stderr is typically forwarded to a log for debugging.
Architecture
Because the client is responsible for launching the server, the server's lifecycle is tied entirely to the client session. When the client exits or restarts, the server process is also terminated and restarted. This tight coupling is a feature in development environments — it means there is no stale server state to worry about — but it limits the transport to single-client, same-machine deployments.
Authentication is implicit: since the client started the process, no token exchange is needed. The server runs with whatever OS-level permissions the client has, making this unsuitable for multi-user environments where per-user authorization matters.
Configuration in `.mcp.json`
Stdio servers are declared with a command and args array in .mcp.json:
{
"mcpServers": {
"local-db": {
"type": "stdio",
"command": "node",
"args": ["./mcp-servers/db-server.js"],
"env": { "DB_PATH": "${DB_PATH}" }
}
}
}The env field supports ${ENV_VAR} expansion so credentials stay out of version control.
stdio vs StreamableHTTP
| Dimension | stdio | [StreamableHTTP](/glossary/streamable-http) |
|---|---|---|
| Server location | Same machine as client | Any network-reachable host |
| Server lifecycle | Managed by client (subprocess) | Independent process/service |
| Multi-client support | Single client only | Multiple concurrent clients |
| Authentication | OS process ownership | Token/header-based |
| Setup complexity | Low (just a command) | Higher (HTTP server required) |
| Best for | Local dev tools, private scripts | Production, team-shared servers |
| Streaming support | Line-by-line stdout | SSE over HTTP |
For a deeper look at how servers are discovered and wired up, see MCP Server Configuration & Scoping.
How It Compares
| Characteristic | stdio | StreamableHTTP |
|---|---|---|
| Process ownership | Client spawns server | Server runs independently |
| Network required | No | Yes |
| Concurrent clients | No | Yes |
| Auth mechanism | Implicit (OS) | Explicit (tokens/headers) |
| Suited for | Dev, CI, local agents | Enterprise, SaaS, shared tooling |
Frequently Asked Questions
Can a stdio server be used in a CI/CD pipeline?
Yes — CI is a single-process environment where the runner spawns the MCP client, which in turn spawns the server. This is a legitimate stdio use case. What it cannot do is serve multiple simultaneous CI jobs sharing a single server instance; each job gets its own subprocess.
Why does stdio make authentication unnecessary?
Because the client process launches the server, the server inherits the client's OS user context. There is no network boundary to cross and no way for another user to connect to the same subprocess. Trust is established at the OS process level rather than through cryptographic credentials.
What happens to server state when the client restarts with stdio?
The old server process is killed and a new one is spawned. Any in-memory state the server held is lost. If your MCP server needs durable state, it must persist it to disk or a database, not rely on process memory — this is one reason production servers migrate to StreamableHTTP with a persistent backing store.