Choose stdio when the MCP server should run on the same machine as one client and use that user's local files and tools. Choose Streamable HTTP when the server should be shared, hosted, or reached from a cloud client. The choice also decides how authentication works and what can go wrong.
What each transport is
The MCP architecture page defines two transports. The stdio transport uses standard input and output streams for direct communication between local processes on the same machine, with no network overhead. The Streamable HTTP transport uses HTTP POST for messages from client to server, with optional Server-Sent Events for streaming.
The same JSON-RPC 2.0 messages travel over both. The docs say local stdio servers typically serve a single client, while remote servers on Streamable HTTP typically serve many.
Where each one fits
Stdio fits a file system helper, a local database tool, a script wrapper, or anything that needs the developer's own environment. The client starts the process, so there is nothing to host.
Streamable HTTP fits a service your company runs once for everyone, a vendor hosted server, or any case where the client is in the cloud. Claude's custom connectors, for example, connect from Anthropic's cloud infrastructure, so the server must be reachable over the public internet. A server on your laptop will not work there.
How authentication differs
Over HTTP, the docs say standard methods work, including bearer tokens, API keys and custom headers, and that MCP recommends OAuth for tokens. Over stdio there is no network handshake. The server inherits what the client gives it, usually through environment variables you set in the config.
Security trade-offs
A stdio server is code that runs with your privileges. The security best practices page lists risks such as a malicious startup command in a configuration, a malicious payload inside the server, or an insecure local server reached by DNS rebinding. It recommends consent dialogs that show the full command, and sandboxing with minimal default privileges.
A remote server moves the risk to the network and identity layer. The same page covers token passthrough, confused deputy problems with proxy servers, and server-side request forgery in clients that fetch URLs.
Neither is safer in general. Local servers need sandboxing and trust in the package. Remote servers need correct OAuth, audience checks, and scoped permissions.
Practical rules
- Default to stdio for personal, local tooling you control.
- Default to Streamable HTTP for shared services and anything a cloud client must reach.
- If you run a local server over HTTP, require an authorization token or use a restricted socket.
- Note that the older SSE transport is described as deprecated in Claude Code's docs, so prefer HTTP where the server supports it.
For more on risks by transport, read MCP transport layer security options.
Quick check
Can a cloud hosted client use my stdio server?
No. A stdio server is a local process started by a client on the same machine. A cloud client needs a remote server over HTTP.
Is stdio automatically safe because it is local?
No. It runs code with the client's privileges, so you still need to trust the package and ideally sandbox it.
Sources
- MCP architecture overview
- MCP security best practices
- Claude custom connectors with remote MCP
- Claude Code MCP documentation
Last reviewed: 19 October 2026.
