MCP vs REST: what changes when agents call your API

The question usually arrives as "should we build an MCP server or a REST API," and it is the wrong question. MCP and REST sit at different layers. REST is how programs integrate with your service. MCP is how AI applications discover and invoke capabilities on behalf of a user, and in practice an MCP server is a curated layer in front of a REST API, not a replacement for it. The interesting comparison is not protocol versus protocol. It is what changes when the caller stops being a developer reading docs and becomes a model choosing tools mid-conversation.

Different layers, different jobs

A REST API optimizes for programmatic integration: stable resources, predictable URLs, fine-grained operations that a developer composes into a workflow, documentation read once while writing code that then runs unchanged for months. The reader and the runner are different things; a human studies the interface, and the program they wrote executes it blindly.

With MCP, the reader and the runner are the same model. It reads your tool list, descriptions, and schemas at call time, every time, and decides in the moment which tool fits the user's request. There is no integration engineer to absorb ambiguity, remember tribal knowledge, or work around a confusing name. Whatever the interface fails to say, the model will guess, and it will guess at scale.

What the shift actually changes

Granularity. REST rewards small composable operations because a developer can chain them. Models are unreliable at long chains: each extra required call multiplies failure odds. Agent-facing tools do better one level higher, as tasks rather than resources. resolve_dispute beats a four-call sequence of GETs and POSTs that a model must orchestrate correctly every single time.

Selection replaces navigation. A developer finds the right endpoint once. A model re-decides on every conversation turn, weighing your tool descriptions against each other. Overlapping tools with vague names produce wrong-tool calls that look like product bugs to the user. Interface design becomes a naming and description problem more than a routing problem, and tool count itself is a design decision: the smaller the menu, the better the choices.

Errors become prompts. A 422 with {"error": "invalid_state"} is fine for a developer with your docs open, and useless to a model mid-task. Agent-facing errors work when they say what to do next: "This payment is already fully refunded. Use get_payment to check refundable_amount before calling create_refund." The model reads the error and self-corrects. Your error strings are now part of the interface, worth reviewing like one.

Auth changes shape. REST integrations authenticate as an application, with a key provisioned once. Agents act on behalf of a person, in sessions, across many users of the same assistant. You need to answer "which user, through which agent, may do what," which pushes toward OAuth for delegated access, scoped keys per consumer, and per-tool authorization rather than one all-or-nothing credential.

The traffic looks different. Our gateway data across 1.2 million tool calls shows agents behaving like a permanent integration test: more read-heavy, more exhaustive across parameters, and immediately sensitive to any change in names or schemas. Rate limiting by request count also stops fitting; a single user request can legitimately fan out into a dozen tool calls, so limits work better per session or per task.

What stays exactly the same

Versioning discipline, backward compatibility, observability, and change review carry over unchanged, and arguably matter more. Renaming a tool breaks an agent workflow precisely the way renaming an endpoint breaks an integration, except the failure shows up in a customer conversation instead of a stack trace. The governance you run on a public API, contracts, breaking-change gates, an announced changelog, is the same governance an MCP server needs from its first day in production. A server without it is a demo.

So which do you build?

Both, in order. The REST API remains the system of record and the thing your MCP server calls. On top of it, expose a deliberately small agent surface: the fifteen or so tasks an assistant should perform, named plainly, described precisely, validated strictly, authenticated per caller, and logged per call. Generate that layer from the API you already have instead of hand-maintaining a second codebase, and diff it on every change like the contract it is. That is the architecture that survives the caller changing from programs to agents, and it is the one Elva generates and hosts.