MCP vs plain APIs: why agents need tools, not endpoints

A plain API exposes endpoints that a developer reads documentation 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.

If you already have a REST API, it is fair to ask what MCP adds. The answer is about who is driving.

An API assumes somebody read the docs

REST is excellent for humans writing integrations. You read the reference, learn that a POST to one path 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. It does not live in the API.

Hand the 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 serves a given goal. You would have to pre-write every call, which means you decided the plan, not the agent. The moment reality differs from what you anticipated, the integration is stuck.

MCP moves that knowledge into the interface

When a client connects to an MCP server it asks for the tool list, and each tool comes back with three things: a name, a description a person can read, and a JSON Schema for its inputs.

Now the model can read the menu at run time. It sees a tool for reading a post’s blocks, understands from the description what that gives it, and knows from the schema what to pass. Nobody pre-wired the call.

That whole config is a name and a URL. Every tool, every description and every schema arrives afterwards, over the connection. The wire-level view is in MCP over HTTP explained and the concept in what is MCP.

What it looks like when it works

ReDock hosts local sites and publishes its whole surface as MCP tools. You could wrap the same capability in a REST API, and then every agent that wanted it would need bespoke integration code first.

As tools, an agent connects and immediately understands it can create sites, start and stop them, author WordPress from real blocks, patch an Elementor widget, share over a tunnel and deploy. In the picture at the top of this post, nobody told the model to read the blocks before patching them. It read the tool descriptions and worked out that reading first was the safe order.

Two design habits make this hold up, and neither is 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 a model can act on. “Site not found, the sites here are X, Y and Z” lets the agent correct itself. A bare status code leaves it guessing.

The part an API never had

There is a third difference that only shows up once an agent is actually calling things: consent and refusal are part of the protocol’s world, not bolted on afterwards.

On ReDock Web, seven switches decide what any connected AI app may do by itself. Switch one off and the app is refused at the door and told to ask a person, and the refusal is on the activity page. Your own team and your own queued jobs are unaffected. An API key has one level: everything the key can reach. A tool surface can have a level per app, per site, and a record of every refusal. AI access on ReDock Web has the detail.

It is not either or

MCP does not replace APIs. It often sits in front of one. A server can wrap existing HTTP APIs and re-present them as tools: the API still does the work, MCP makes it legible to a model.

The question is not “API or MCP”, it is “who is the consumer”. People writing integrations want APIs. Agents deciding at run time want tools.

Where those tools live is a separate decision, and Local MCP vs remote MCP covers it.

FAQ

Can I just give an agent my REST API?

You can, and you will have to pre-write every call, which means you planned the workflow rather than the agent. MCP lets the model discover and choose at run time.

Does MCP replace my existing API?

No. It commonly wraps one and re-presents it as self-describing tools. The API still does the work.

What actually makes a tool self-describing?

A name, a description and a JSON Schema for its inputs, all delivered when the client connects, so an agent knows what a tool does and how to call it without hardcoded knowledge.

Is a tool surface safer than an API key?

It can be, because permission can be finer. A key usually means everything the key reaches. An approved MCP app can be held to one level, on one site, with every refusal recorded and revocation taking effect on the next call.

ReDock is a whole local web stack presented as tools rather than endpoints you have to wire up. Download it for macOS or Windows.