What is the stdio Transport?

stdio is one of two standard transports defined by the Model Context Protocol, alongside the Streamable HTTP transport. The spec says clients SHOULD support stdio whenever possible, and it remains the default way to run a local MCP server from clients like Claude Code or Cursor.

The mechanics are deliberately simple: the client spawns the server process, writes JSON-RPC messages to its stdin, and reads responses from its stdout. Messages are delimited by newlines and must not contain embedded newlines. The server may write logs to stderr, but must not write anything to stdout that is not a valid MCP message.

The transport choice has operational consequences:

• Process lifetime — the server lives and dies with the client session; shutdown is signalled by closing stdin, then SIGTERM, then SIGKILL.
• Credentials via environment — stdio servers typically receive API keys as environment variables in the client's MCP JSON configuration, with the full privileges of the local user.
• No network authorisation layer — there is no HTTP layer, so MCP's OAuth-based authorisation does not apply; access control is whatever the local process can reach.
• Invisible to network controls — traffic never crosses a network boundary, so proxies and egress filters cannot observe it.

PolicyLayer's public catalogue at policylayer.com/tools classifies the tools exposed by thousands of MCP servers, most of which are distributed as stdio packages on npm. The npx policylayer CLI scans the stdio servers in a local MCP configuration and reports per-tool risk before they reach an AI client.

For fleet enforcement, teams route clients through the PolicyLayer gateway over HTTP, which brings the policy evaluation and audit trail that a directly-spawned stdio subprocess cannot provide on its own.