Everything we have built so far runs on one machine. The host launches the MCP server as a subprocess, the client talks to it over stdio, and both processes live on the same laptop. That is the right default for local development, personal tools, and many desktop workflows. It is the wrong 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 must spawn the server directly. There is no URL, no load balancer, no TLS termination point, and no clean way for a client on Machine A to reach a server on Machine B. If five developers need the same MCP wrapper around internal APIs, stdio means five local installs, five local credential configurations, and five upgrade paths.

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

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