MCP vs plain APIs: why agents need tools, not endpoints
An API exposes endpoints a developer wires up; MCP exposes self-describing tools an agent discovers and calls on its own. That difference is the whole point.
A plain API exposes endpoints that a developer reads docs for and writes code against; MCP exposes self-describing tools that an agent discovers at runtime and calls on its own. Same underlying capability, different consumer. An API is built for a programmer who plans ahead; MCP is built for a model deciding what to do next. That’s why agents reach for MCP tools instead of raw endpoints.
If you already have a REST API, it’s fair to ask what MCP adds. The answer is about who’s driving.
An API assumes a programmer read the docs
REST is excellent — for humans writing integrations. You read the reference, learn that POST /sites takes this body and returns that shape, and you write code that encodes all of it. The knowledge lives in your head and in your source, not in the API.
Hand that same API to a model and the gap shows. The model has no built-in knowledge of your routes, your auth, your field names, or which endpoint to call for a given goal. You’d have to pre-write every call, which means you — not the agent — decided the plan in advance. The moment the situation differs from what you anticipated, the integration is stuck.
MCP makes the interface self-describing
MCP flips the ownership of that knowledge. When a client connects to an MCP server, it asks for the tool list, and each tool comes back with:
- a name,
- a human-readable description of what it does, and
- a JSON Schema describing its inputs.
Now the model can read the menu at runtime. It sees a tool called “create site,” understands from the description what it does, and knows from the schema what to pass. Nobody pre-wired the call. This discovery step is the mechanical difference between MCP and a plain API — the wire-level view is in MCP over HTTP explained, and the concept in what is MCP.
Why this matters for real work
Consider ReDock, which hosts local sites and exposes its whole surface as MCP tools on localhost:47200. You could imagine wrapping the same functionality in a REST API. But then every agent that wanted to use it would need bespoke integration code. As tools, an agent connects and immediately understands it can create sites, start and stop them, author WordPress with Gutenberg blocks, share over Cloudflare tunnels, and deploy to Workers — no pre-wiring per client. The full tools list is what the agent discovers.
Two design habits make the tool-shaped surface work in practice, and they’re worth naming because they’re not automatic:
- Descriptions written for a model. A tool description is a prompt. “Create a local site at name.test” tells the model when to reach for it; a terse endpoint name does not.
- Errors the model can act on. ReDock returns “site not found — valid sites are X, Y, Z” instead of a bare 500. The agent can correct itself and retry. A plain status code leaves it guessing.
It’s not either/or
MCP doesn’t replace APIs; it often sits in front of them. A server can wrap existing HTTP APIs and re-present them as tools — the API still does the work, MCP makes it agent-legible. The question isn’t “API or MCP,” it’s “who’s the consumer.” Humans writing integrations want APIs. Agents deciding at runtime want tools.
Where those tools live is a related decision — local for reach into your machine, remote for shared services. Local MCP vs remote MCP covers that trade-off, and the MCP docs show ReDock’s surface.
FAQ
Can’t I just give an agent my REST API?
You can, but you’ll have to pre-write every call, which means you planned the workflow, not the agent. MCP lets the model discover and choose tools at runtime.
Does MCP replace my existing API?
No. MCP commonly wraps an existing API and re-presents it as self-describing tools. The API still does the work.
What actually makes a tool “self-describing”?
Each tool ships a name, a description, and a JSON Schema for its inputs, delivered at connect time — so an agent knows what it does and how to call it without hardcoded knowledge.
ReDock is a full local web stack presented as agent-ready tools, not endpoints you have to wire up — download ReDock.