MCP Transports — Cheat Sheet
Curso MCP Engineering · M1
This guide explains, from scratch and taking nothing for granted, what a transport is and how to choose between the two that matter today: stdio and Streamable HTTP. Choosing the right transport is the first practical decision you'll make when building a server.
In one sentence
A transport is the channel through which messages travel between the client and the server in MCP. The protocol defines what they say; the transport, where through. The same conversation can travel through different channels — like a letter you send by post or by email: the content is the same, the medium changes.
The key question
Does the server run on YOUR machine or on the NETWORK?
- On your machine → stdio
- On the network (others connect over the internet) → Streamable HTTP
With that single question you solve 95% of cases. Everything else is details.
stdio: the server lives on your machine
stdio stands for standard input / standard output: two "pipes" of text that every terminal program already has. With this transport, the MCP server runs as a local subprocess —a program that the host starts on your own computer— and messages go back and forth through stdin (input) and stdout (output).
- It's the simplest: no network, no ports, no URLs to configure.
- It has the lowest latency: everything happens inside your machine, without going out to the internet.
- Ideal for local and desktop tools (for example, a server that reads files from your disk from Claude Desktop).
If you're getting started, stdio is where you'll build your first server.
Streamable HTTP: the server lives on the network
When the server isn't on your machine but somewhere else —a remote server that many people connect to over the internet— you use Streamable HTTP (introduced in the version of the specification 2025-03-26).
- It exposes a single HTTP endpoint (a URL) to which the client sends messages.
- It can use SSE (Server-Sent Events), a technique for the server to send data to the client in streaming — useful for long responses or messages the server initiates on its own.
- It supports sessions, resumability (resuming a connection that dropped) and the
MCP-Protocol-Versionheader to agree on which protocol version is being used.
It's the path for remote or hosted servers.
Decision table
| Transport | When to use it | Pros | Cons |
|---|---|---|---|
| stdio | Local or desktop tool; the server runs as a subprocess on your machine | The simplest; no network or ports; lowest latency; ideal for getting started | Local only; not for remote access |
| Streamable HTTP (spec 2025-03-26) | Remote or hosted server that others connect to over the network | A single HTTP endpoint; optional SSE for streaming; sessions, resumability, MCP-Protocol-Version header | More pieces to configure; requires security precautions (Origin, binding) |
| HTTP+SSE (spec 2024-11-05) | ❌ Don't use in new projects | — | Deprecated: replaced by Streamable HTTP |
⚠️ HTTP+SSE is deprecated
Before Streamable HTTP there was another network transport called HTTP+SSE (from version 2024-11-05). It worked, but it was more rigid: it used two separate channels and didn't handle reconnections or sessions well. Streamable HTTP replaces it and does everything in a single endpoint, more robust. That's why HTTP+SSE became deprecated (obsolete): it still appears in old tutorials, but for anything new don't use it. If you see "HTTP+SSE" in a guide, it's a sign that it's out of date — choose Streamable HTTP.
Don't confuse them: "SSE" (Server-Sent Events) is a streaming technique that Streamable HTTP still uses. What's deprecated is the complete HTTP+SSE transport from 2024, not the SSE technique itself.
Security note on network transports
Network transports require precautions that stdio doesn't need, because they open a door to the world. Two basics to keep on your radar:
- Validate the
Originheader on every request, to prevent malicious sites from talking to your server from the browser. - Listen only on
localhostwhen the server is local (instead of on all network interfaces), so you don't accidentally expose it to the network.
Don't worry about the details now: they're covered in depth in a lesson dedicated to security later on. It's enough to know that the network calls for precautions that local doesn't.
Glossary
- Transport: the channel through which MCP messages travel between client and server.
- stdio: local transport; the server is a subprocess and uses stdin/stdout.
- Streamable HTTP: network transport (spec 2025-03-26); one HTTP endpoint, with optional SSE.
- SSE (Server-Sent Events): technique for the server to send data to the client in streaming.
- HTTP+SSE: old network transport (2024-11-05), deprecated.
- Endpoint: the address (URL) to which the client sends the messages.
- Subprocess: a program that another program (the host) starts inside your machine.
- Latency: the time it takes a message to go and come back.
- Session / resumability: maintaining and resuming the state of a connection that dropped.
MCP-Protocol-Version: HTTP header to agree on the protocol version.
To remember
- stdio = local, subprocess, stdin/stdout → your first server goes here.
- Streamable HTTP = network, one endpoint, optional SSE → for remote servers.
- HTTP+SSE = old and deprecated → don't use it (but the technique SSE is still alive).
- Network security (validate
Origin, listen only on localhost): keep it on your radar; it's covered in depth later. - The decision comes from a single question: on my machine or on the network?
Turning Point Academy · MCP Engineering Course · Module 1 · Transports