Every MCP server needs a transport layer. It is the wire between your agent and the server, the part that carries JSON-RPC messages back and forth. MCP gives you three options: stdio, SSE, and HTTP. Each one makes different tradeoffs around simplicity, deployment model, and scalability.
Pick the wrong one and you will fight your infrastructure instead of building with it. Here is how to think through the choice.
The Three Transport Modes
Stdio: Local Pipes
Stdio is the default. When you add a server to Claude Desktop or Claude Code, the host launches the server as a child process on your machine. Messages flow through stdin and stdout. No network involved.
Out of the 438 MCP servers listed on AgentNDX, 351 use stdio. That number is not accidental. Stdio is the fastest way to get a server running. No port configuration, no TLS, no CORS. You point your host at a command, it spawns the process, and you are connected.
How it works:
- The host reads your config and finds the server command
- It spawns that command as a child process
- JSON-RPC messages go to the child’s stdin
- Responses come back on stdout
- Stderr is available for logging without interfering with the protocol
Where it fits:
- Local development tools (filesystem access, git, database queries)
- Personal automation (your own scripts, local APIs)
- CLI-based workflows where the agent and server share a machine
- Any situation where “install and run” is the entire setup
Where it breaks:
- You cannot share a stdio server across machines. It is bound to the process that launched it.
- Scaling means spawning more processes. There is no connection pooling or load balancing.
- Remote agents cannot reach a stdio server without tunneling, which adds complexity you were trying to avoid.
HTTP: Request-Response Over the Network
HTTP transport wraps MCP in standard HTTP requests. The agent sends a POST with a JSON-RPC payload, the server responds with the result. Stateless, familiar, and compatible with every proxy, load balancer, and CDN on the planet.
85 servers on AgentNDX use HTTP transport today, and that number grows every week as more teams deploy MCP servers as hosted services.
How it works:
- The agent sends an HTTP POST to the server endpoint
- The request body contains the JSON-RPC message
- The server processes the request and returns the response in the HTTP body
- Each request is independent. No persistent connection required.
Where it fits:
- Cloud-hosted MCP servers (Railway, Cloudflare Workers, AWS Lambda)
- Multi-tenant services where many agents connect to one server
- APIs that already run behind HTTP infrastructure (auth gateways, rate limiters, WAFs)
- Production deployments where you need observability, caching, and standard HTTP tooling
Where it breaks:
- Every interaction is a round trip. If your server needs to push updates or stream partial results, pure HTTP request-response will not cut it.
- Latency is higher than stdio for local operations. Adding HTTP overhead to a filesystem read is wasteful.
- You need to handle auth, TLS, and CORS. More infrastructure surface area than stdio.
SSE: Server-Sent Events for Streaming
SSE sits between the other two. The agent opens a long-lived HTTP connection and the server pushes events down that connection as they happen. Think of it as HTTP with a persistent downlink.
Only 2 servers on AgentNDX use SSE today. It is the newest transport option and adoption is still early. But for certain use cases, it is the right tool.
How it works: The agent opens a long-lived HTTP connection to the SSE endpoint. The server pushes events (tool results, progress updates, resource changes) down that connection. The agent sends its own requests via POST to a separate endpoint. Responses arrive on the SSE stream.
Where it fits:
- Long-running operations where you want progress updates
- Monitoring servers that push metrics or alerts
- Any server where the agent needs to react to events, not just request data
Where it breaks:
- Not all proxies and load balancers handle long-lived connections well.
- You need reconnection logic, heartbeats, and timeout handling.
- Overkill for simple request-response patterns. If your server just answers questions, HTTP is simpler.
Side-by-Side Comparison
| Factor | Stdio | HTTP | SSE |
|---|---|---|---|
| Setup difficulty | Minimal | Moderate | Higher |
| Network required | No | Yes | Yes |
| Deployment model | Local only | Local or remote | Local or remote |
| Scalability | Per-process | Standard web scaling | Moderate (connection limits) |
| Streaming support | No | No | Yes |
| Auth required | No (local process) | Yes | Yes |
| Proxy/CDN compatible | N/A | Yes | Partial |
| Server count on AgentNDX | 351 | 85 | 2 |
Decision Framework
Start with one question: does the agent and the server run on the same machine?
If yes, use stdio. You get zero-config setup, no network overhead, and the fastest possible message passing. There is no reason to add HTTP complexity for a local tool.
If no, ask a second question: does the server need to push data to the agent without being asked?
If the server only responds to requests, use HTTP. You get the entire web infrastructure stack for free. Deploy to any cloud platform, put it behind a load balancer, add rate limiting and auth with standard tools.
If the server needs to stream updates or push events, use SSE. Accept the added connection management complexity in exchange for real-time data flow.
Two more considerations:
-
Team size matters. Solo developer building for yourself? Stdio covers 90% of use cases. Building a service for others? HTTP is the starting point.
-
The spec is evolving. HTTP Streamable transport (a newer addition to the MCP spec) blends HTTP and SSE capabilities. If you need streaming later, building on HTTP gives you the cleanest upgrade path.
FAQ
Q: Can I switch transport later without rewriting my server? A: The transport layer is mostly separate from your tool and resource logic. Most MCP SDKs let you expose the same server over multiple transports by changing the startup configuration. Your tool handlers stay the same.
Q: What about WebSocket transport? A: The MCP spec does not include a native WebSocket transport as of May 2026. Some community implementations exist, but they are not part of the official protocol. SSE covers most bidirectional streaming cases today.
Q: Which transport should I use for a production SaaS product? A: HTTP. It works with every deployment platform, every monitoring tool, and every security proxy. SSE is worth adding alongside HTTP if your product involves long-running jobs or real-time updates, but HTTP should be the baseline.
Q: Is stdio less secure than HTTP? A: Different threat model, not less secure. Stdio servers run as local processes with the same permissions as your user account. There is no network exposure by default. HTTP servers are network-accessible and need proper auth, TLS, and input validation. Each model has its own security considerations.