The Model Context Protocol (MCP) is an open standard that lets AI clients connect to external tools and data. Every MCP server uses one of two transports. Choosing the right one is your first architectural decision, and it maps directly onto the “local vs remote” distinction.
The one-line rule #
If the person using the AI client also controls the machine the server runs on, use STDIO (local). If they don’t, use Streamable HTTP (remote). Everything below is detail on top of that.
Local servers → STDIO transport #
The client spawns the server as a child process and communicates over standard input/output. Each message is a JSON-RPC 2.0 message written to the process streams and delimited by a newline: the client writes to the server’s STDIN, the server replies on STDOUT.
Strengths:
- Universally supported — every MCP client speaks STDIO. It is the lowest common denominator.
- Secure by default — communication stays on the local machine through OS-level pipes, so there is no network surface to attack. The server inherits the client’s permissions.
- Easy to debug — you can test a server by piping JSON to it from the command line.
Tradeoffs:
- Local only — the server must be installed on the same machine as the client; you can’t share it across a team.
- One process per connection — each client connection spawns a new server process, which doesn’t scale for shared infrastructure.
- Per-machine installation and updates — every instance is installed and updated separately.
Best for: desktop apps, IDEs, local development, and any tool tightly coupled to a single user’s machine.
Remote servers → Streamable HTTP transport #
The server runs as an independent service and clients talk to it over HTTP. It exposes a single HTTP endpoint that handles both POST (client-to-server messages) and GET. This makes it far more suitable for remote access, shared services, and serving many clients at once. Streamable HTTP was introduced in MCP spec version 2025-03-26 and is the current standard for remote servers.
Best for: hosted/shared servers, multi-client and team scenarios, zero-installation setups, and centrally managed services.
What about SSE? #
Server-Sent Events (SSE) was MCP’s original remote transport (spec version 2024-11-05). It required two separate endpoints — a GET for the SSE stream and a POST for client messages — and that dual-endpoint design was awkward. Streamable HTTP replaced it by consolidating everything into a single endpoint and making SSE an optional streaming mechanism rather than a mandatory standalone transport.
You will still encounter /sse URLs in the wild, because many hosted servers continue to expose them. But for any new implementation, use Streamable HTTP.
Quick comparison #
| STDIO (local) | Streamable HTTP (remote) | |
|---|---|---|
| Where it runs | Same machine as the client | Independent service over HTTP |
| Clients served | Typically one | Many concurrent clients |
| Installation | Per machine | None for the client |
| Security surface | No network surface | Needs auth (OAuth 2.1 / Bearer tokens) |
| Spec status | Current | Current (replaced HTTP+SSE) |
The transport is independent of the protocol itself — both carry the same JSON-RPC MCP messages, so switching transports doesn’t change a server’s tools or data contracts. The next article covers how each AI client expects you to configure these servers, which is where the formats diverge.
