MCP transport: stdio vs HTTP/SSE — which one should a solo founder actually run?

The short answer If your Model Context Protocol server runs on the same machine as your client, use stdio. It is faster, simpler to debug, and has no network surface to babysit. If your server runs as a remote service that one or more clients connect to over a network, use Streamable HTTP. The MCP spec has deprecated the older HTTP plus SSE transport. SSE stays around for backwards compatibility, but new work should sit on Streamable HTTP. That is the headline. The rest of this guide unpacks the trade-off in detail, and what each choice does to your incident response. Why transport choice matters for a solo founder You run an MCP server so some agent can call tools and read resources over JSON-RPC 2.0. The protocol is deliberately wire-format agnostic, so the messages are the same regardless of transport. What changes is everything around them: how the process starts, how it dies, how you observe it, and how you recover at two a.m. For a one-person backend, the right transport matches where the client and server actually live, gives you a sane reconnect story, stays observable from a single laptop, and does not force you to stand up TLS, auth, and rate limiting just to call a tool locally. stdio in one paragraph stdio is process-to-process communication. Your MCP client launches the server as a subprocess, writes JSON-RPC messages to its stdin, and reads responses from its stdout. There is no network, no port, no TLS, no CORS, no firewall. The OS pipe is the security boundary. The MCP spec recommends it whenever the client can launch the server directly, and it is the most widely deployed option in practice. Messages are newline-delimited JSON-RPC 2.0. Logging must go to stderr, never stdout, because stdout is reserved for protocol messages. The HTTP family: SSE, then Streamable HTTP The MCP spec originally defined a remote transport called HTTP plus SSE, with two endpoints: a long-lived GET streaming server-to-client events, and a POST for messages. The current spec replaces that with Streamable HTTP. A single endpoint accepts POSTs and optionally upgrades to SSE for streaming responses. Sessions can be stateful or stateless, and stateless is the SDK's recommendation for production scalability. Streamable HTTP supports resumability, so a dropped connection can replay from the last event ID. Authentication uses a real Authorization header, with first-class OAuth flows. The deprecated HTTP plus SSE transport remains for backwards compatibility only. A decision framework for a solo founder Walk through these questions in order. Does the client and server run on the same machine? Use stdio and ship. Does a remote agent need to call this server from a different host? Use Streamable HTTP, stateless if you do not need per-session state, behind a reverse proxy. Are you maintaining a desktop or sandboxed app that cannot easily launch subprocesses? This is an edge case the MCP maintainers have flagged, and for a new build today it usually still means Streamable HTTP from the client side. Are you stuck supporting a legacy client that only speaks the old HTTP plus SSE? Keep an SSE-compatible endpoint around, but isolate it. Monitoring and the final word For stdio, monitor exit codes, stderr, process count, and round-trip latency from the parent. For Streamable HTTP, monitor HTTP status codes by route, latency percentiles, active sessions, reconnect events, resumable-stream retries, and standard access logs. The honest takeaway: default to stdio while the server runs on the same machine as the client, and switch to Streamable HTTP the moment it goes remote. The decision is mostly about deployment context, not preference. For the full trade-off tables and source links, read the original article linked in the description.