Transports: stdio and Streamable HTTP
What the Transport Layer Does
The transport layer is responsible for getting JSON-RPC messages from one side to the other. It handles connection establishment, message framing (knowing where one message ends and the next begins), and — for networked transports — authentication. MCP defines exactly two official transport mechanisms today: stdio and Streamable HTTP.
Accuracy note: SSE is not a separate transport anymore
Older tutorials list 'WebSockets' or a standalone 'SSE' transport. The current spec defines only two: stdio and Streamable HTTP. Server-Sent Events still exist, but as an OPTIONAL streaming mechanism inside Streamable HTTP — not as their own transport. When you see 'HTTP+SSE transport' in old docs, read it as 'Streamable HTTP'.
stdio — Local and Fast
The stdio transport uses the operating system's standard input and standard output streams to pass messages between two processes on the same machine. The host launches the server as a subprocess and writes JSON-RPC messages to its stdin, reading replies from its stdout. There's no network, no ports, and no HTTP overhead — making it the fastest option and the default for local servers.
- •Best for: local integrations like filesystem, a local database, or a script on your machine.
- •Serves: typically a single client (the host that launched it).
- •Credentials: read from the environment (env vars) — the OAuth flow does NOT apply to stdio.
- •Performance: optimal — direct process I/O with no network hop.
# A server chooses stdio simply by how it runs:
if __name__ == "__main__":
mcp.run(transport="stdio")Streamable HTTP — Remote and Multi-Client
The Streamable HTTP transport uses HTTP POST for client-to-server messages, with optional Server-Sent Events (SSE) for streaming responses back. This is what enables remote servers: it works across the network and supports standard HTTP authentication — bearer tokens, API keys, custom headers — with MCP recommending OAuth to obtain those tokens (covered later).
- •Best for: hosted/remote servers shared by many users (e.g. the Sentry MCP server).
- •Serves: many clients concurrently.
- •Auth: standard HTTP auth; OAuth 2.1 is the recommended way to obtain tokens.
- •Streaming: optional SSE lets the server stream partial results over a single response.
# The same server can instead run over Streamable HTTP:
if __name__ == "__main__":
mcp.run(transport="streamable-http")Choosing a Transport
| Question | stdio | Streamable HTTP |
|---|---|---|
| Where does the server run? | Same machine as the host | Anywhere reachable over HTTP |
| How many clients? | Usually one | Many concurrently |
| How are credentials handled? | Environment variables | HTTP auth / OAuth tokens |
| Network overhead? | None (direct process I/O) | Standard HTTP |
| Typical use | Local dev tools, filesystem, local DB | SaaS / shared remote servers |
Pick stdio for local single-client servers; pick Streamable HTTP for remote, multi-client servers.
The transport is invisible to your logic
Because the data layer is identical across transports, your tool, resource, and prompt definitions don't change when you switch from stdio to Streamable HTTP. You write the server once and choose the transport at run time. This is the practical payoff of MCP's two-layer design.
End of the Foundations section
You now understand WHO talks (host/client/server) and HOW (data layer over stdio or HTTP). Next section traces a real request end-to-end, then we start building servers with the Python SDK.
Key Takeaways
- ✓The transport layer handles connection setup, message framing, and authentication for moving JSON-RPC messages.
- ✓MCP defines exactly two official transports: stdio (local) and Streamable HTTP (remote).
- ✓SSE is no longer a standalone transport — it's an optional streaming mechanism inside Streamable HTTP; 'HTTP+SSE' in old docs means Streamable HTTP.
- ✓stdio uses OS stdin/stdout between local processes: no network, fastest, usually one client, credentials from environment variables (no OAuth).
- ✓Streamable HTTP uses HTTP POST (+ optional SSE streaming), works remotely, serves many clients, and supports HTTP auth with OAuth-obtained tokens.
- ✓Switching transport is a one-line change because the data layer is identical — your tools/resources/prompts never change.
Check Your Understanding
Test what you learned in this lesson.
Q1.How many official transport mechanisms does the current MCP spec define, and what are they?
Q2.Which transport is the natural choice for a local filesystem server launched by Claude Desktop?
Q3.How are credentials handled for a stdio-based MCP server?
Q4.Why can you switch a server from stdio to Streamable HTTP with essentially a one-line change?
Practice This Lesson