Everything we have built so far runs on one machine. The host starts the MCP server as a subprocess, the client talks to it over stdio, and both processes live on the same laptop. That is a good default for local development, personal tools, and many desktop workflows. It is not the right shape when the server must be shared by a team, reached by cloud-hosted agents, or operated as a service.

Stdio is a local process transport. The client starts the server directly. There is no URL, no load balancer, no TLS termination point, and no clean way for a client on one machine to reach a server on another. If five developers need the same MCP wrapper around internal APIs, stdio usually means five local installs, five local credential setups, and five upgrade paths.

Remote MCP servers solve that deployment problem. Instead of communicating through stdin and stdout, the server exposes an HTTP endpoint that authorized clients can reach over the network. The MCP specification defines Streamable HTTP as the standard remote transport.

Streamable HTTP keeps normal requests straightforward: one HTTP POST carries one JSON-RPC message. When a response or server notification needs streaming, the transport can use Server-Sent Events (SSE).