Stdio Transport

Stdio transport is the simplest way to run a Model Context Protocol server: the client spawns the server as a child process and exchanges JSON-RPC messages over the process's standard input and standard output streams. No network, no ports, no TLS — just two processes talking through pipes on the same machine.

It is the default transport for locally installed servers distributed via npm, PyPI, or as standalone binaries. When a Claude Desktop or Cursor config file specifies a command like npx or uvx with a package name, that server runs over stdio.

The client launches the configured command, then writes newline-delimited JSON-RPC messages to the server's stdin and reads responses from its stdout. The server's stderr is left free for logging, which is why MCP servers must never print non-protocol output to stdout — a stray console.log corrupts the message stream and is one of the most common causes of a server failing to connect.

The server's lifetime is tied to the client session: it starts when the client launches it and exits when the pipe closes. There is no separate deployment, health check, or uptime concern.

Stdio shines when the server needs local context: reading the user's filesystem, driving a local browser, or querying a database reachable from the developer's machine. It also inherits the user's local environment, so credentials can come from environment variables in the client config rather than a hosted secret store.

For tool authors, stdio is the lowest-friction distribution path — publish a package and any MCP client can run it with a one-line config entry. The Loomal Index lists thousands of stdio-distributed servers alongside remote ones, with the install command on each listing.

Stdio is inherently single-user and local. There is no way to share one running instance across users, no network boundary to attach authentication to, and no request/response surface where payment middleware could intervene. The transport has no built-in support for per-call billing.

This is why x402 monetization targets remote servers. A payment gate needs an HTTP exchange to return a 402 challenge and verify payment before the handler runs; a subprocess piping JSON over stdin has no equivalent interception point. Servers that want to charge per call typically expose a hosted Streamable HTTP endpoint, sometimes alongside an open-source stdio distribution.

Choose stdio for local capability and zero-ops distribution; choose Streamable HTTP when the server should be multi-tenant, centrally updated, or monetized. Many projects ship both: the free stdio package for self-hosters and a hosted remote endpoint with per-call USDC pricing.

On the Loomal Index, that pattern maps to a single claimed listing whose owner can attach x402 pricing (minimum $0.01 per call) to the hosted endpoint while the open-source package remains freely installable — the software stays free; the hosted calls are what carry a price.