What is STDIO Transport?
STDIO Transport is a local Model Context Protocol transport that exchanges protocol messages between an MCP Client and an MCP Server over a child process standard input and output streams.
Quick Facts
| Specification | Official Specification |
|---|
How It Works
STDIO Transport is the simplest and most common way to run local MCP servers. The host starts a server process, writes JSON-RPC messages to its standard input, and reads responses or notifications from standard output. This design is convenient for developer tools, local scripts, and desktop integrations because it avoids opening network ports. It also requires discipline: logs must go to stderr, message framing must be correct, and the host should treat the child process as a bounded trust relationship.
Key Characteristics
- Local process model: the host launches or manages the MCP Server as a child process
- No network listener: communication uses stdin and stdout instead of an exposed TCP port
- JSON-RPC message stream: protocol messages must be framed and written correctly
- Developer-friendly: well suited for local tools, CLIs, IDE extensions, and desktop assistants
- Process lifecycle concerns: requires handling startup, crash, cancellation, stderr logs, and cleanup
Common Use Cases
- Running a local filesystem MCP Server from a desktop AI application
- Connecting an IDE agent to repository tools without exposing a network service
- Wrapping a command-line utility as a local MCP integration
- Testing MCP server behavior during development
- Deploying user-scoped tools that should not be reachable over the network
Example
Loading code...Frequently Asked Questions
Why use STDIO Transport instead of HTTP?
STDIO is simple for local integrations. It avoids network exposure, authentication setup, and port conflicts, making it a good fit for desktop apps, IDEs, and local command-line tools.
Where should an MCP Server write logs when using stdio?
Logs should go to stderr, not stdout. Stdout is reserved for protocol messages; mixing logs into stdout can corrupt the JSON-RPC stream.
Is STDIO Transport suitable for remote services?
No. It is a local process transport. Remote services should use an HTTP-based transport with proper authentication, authorization, and network controls.
What are common stdio implementation mistakes?
Common mistakes include writing logs to stdout, incorrect message framing, not handling process crashes, leaving child processes running, and assuming local tools are automatically safe.