MCP Transports: stdio vs Streamable HTTP Explained

Same protocol, two very different deployments. An MCP server can be a program running on your own laptop, talking to the host through standard input and output — or a service on the internet serving thousands of users over HTTP. The messages are identical; almost everything else — authentication, security posture, operational burden — is not. This short lesson is how to choose, and the two questions that decide it.

The two transports

stdio — the server as a local subprocess

The host launches the server as a child process and they exchange JSON-RPC messages over stdin and stdout. No ports, no network exposure, no TLS to configure. The server runs with the user's own local permissions, so credentials typically come from the environment.

if __name__ == "__main__":
    mcp.run()          # stdio by default: reads stdin, writes stdout

This is the most common setup for desktop and developer tooling — filesystem access, local git, a database on your machine. It's also the simplest to reason about: if the data never leaves the machine, neither should the protocol.

💡 The trap everyone hits once: on stdio, stdout is the wire. Any print() in your server corrupts the message stream and produces baffling parse errors. Logs go to stderr or a file — never stdout (lesson 8).

Streamable HTTP — the server as a network service

For remote servers, MCP uses streamable HTTP — HTTP-based messaging with streaming support. (Earlier revisions of the spec paired HTTP with SSE; knowing that history is worth a mark, because plenty of tutorials still show the older approach.)

Now the server is an ordinary internet-facing service, and inherits every ordinary obligation: authentication, per-user authorization, tenant isolation, rate limiting, TLS, logging, uptime. Nothing about MCP removes those — it just means the payloads happen to be JSON-RPC.

Wait — where do credentials come from?

This is the sharpest practical difference between the two.

stdio: the server is already running as the user, so it typically picks up credentials from the local environment — an environment variable, a config file, an existing session. There's no separate identity to establish, because the process is the user.

Remote HTTP: the server has no idea who is calling until told. It needs real authentication (commonly OAuth-based) and, just as importantly, per-user authorization — the tools must act with the calling user's permissions, not with a single powerful service account that can see everything.

A shared super-user token behind a multi-user MCP server is the classic security mistake — every user effectively inherits every permission the token has, and the model becomes a very cooperative way to exercise them.

What stays the same

The protocol itself: the same JSON-RPC messages, the same capability handshake, the same tools, resources and prompts. Your server's logic and tool definitions don't change with the transport — which is why a server can often move from local to remote with configuration rather than a rewrite.

That separation is the point of having a transport layer at all, and it's a clean thing to say in an interview: transport changes delivery and security posture, not semantics.

Choosing — just two questions

Selection-round radar: "What transports does MCP support and when would you use each?" Answer: stdio for local subprocess servers (one user, local data, credentials from the environment); streamable HTTP for remote multi-user servers (real authentication, per-user authorization, rate limiting) — and note that streamable HTTP replaced the earlier HTTP+SSE approach.

Common mistakes

• Printing logs to stdout in a stdio server — corrupts the protocol stream.
• Exposing a local, single-user tool over HTTP and creating an attack surface for nothing.
• Running a multi-user remote server on one shared super-user token.
• Assuming a remote MCP server needs less hardening than any other internet-facing service.
• Citing HTTP+SSE as the current remote transport — it was superseded by streamable HTTP.

Quick recap

Practice Zone — PYQs from real selection rounds

Six MCQs and a routing task — pick the transport for four real deployments and justify each.

Q1MCP transportsmedium

The stdio transport is used when:

Asked in

aThe server runs remotely in another data centrebThe server runs as a local subprocess of the host, communicating over standard input/outputcThe client is a web browserdThe connection needs OAuth

Q2MCP transportsmedium

For a remote MCP server accessed over the network, the current transport is:

Asked in

aFTPbStreamable HTTP — HTTP-based messaging with streaming support, which replaced the earlier HTTP+SSE approachcRaw TCP sockets onlydWebRTC

Q3MCP transportsmedium

How does authentication differ between the transports?

Asked in

aBoth require OAuthbstdio inherits the local process's environment and credentials, while remote HTTP servers need real authentication and authorization (commonly OAuth-based)cNeither supports authenticationdstdio requires stronger authentication than HTTP

Q4MCP transportshard

Which is a genuine risk specific to remote MCP servers?

Asked in

aThey cannot expose toolsbThey're multi-tenant network services — so they need authentication, per-user authorization, rate limiting, and careful isolation between users' datacThey cannot use JSON-RPCdThey must run on the user's laptop

Q5MCP transportseasy

For a personal developer tool that reads local files, the sensible transport is:

Asked in

aRemote HTTP with OAuthbstdio — a local subprocess, no network exposure, running with the user's own permissionscEither, they're identical in practicedNeither; use a database connection

Q6MCP transportsmedium

What stays the same across transports?

Asked in

aNothing — each transport has its own protocolbThe protocol itself — the same JSON-RPC messages, capability handshake and primitives; only the delivery mechanism differscThe authentication schemedThe programming language of the server

Hands-on task:

FAQ

Next lesson: write one yourself — Lesson 5: Build an MCP Server →