MCP vs APIs
By Matt Doughty, CEO & Co-Founder of Prefactor ·
MCP is not a rival to your APIs — it is a layer that makes them usable by AI models. A REST API assumes a developer reading documentation; an MCP server assumes a model reading tool descriptions mid-task. The question is never which to build instead, but whether the consumers of a capability now include agents.
| Dimension | MCP | Plain APIs |
|---|---|---|
| Designed consumer | A model, deciding mid-task | A developer, reading docs |
| Discovery | Runtime — client asks what tools exist | Documentation and SDKs, at build time |
| Interface contract | Tool descriptions and schemas the model interprets | Endpoints and types a human codes against |
| Integration cost | One server serves every MCP client | Bespoke glue per application |
| Granularity | Curated verbs — a handful of purposeful tools | Full surface — every endpoint exposed |
| Credential position | Held by the server, invisible to the model | Held by each calling application |
The verdict
Keep your APIs exactly as they are — MCP consumes them rather than replacing them. Add an MCP server in front of a system when agents become its consumers, and treat that server as a curation exercise: the handful of well-described tools an agent can use safely, not a one-to-one mirror of the API. If no agent will touch the system, MCP adds a layer for nobody; if agents already reach it through bespoke integrations, the server is how you stop maintaining that glue per application and start enforcing limits in one place.