WordPress REST API vs MCP: which should your AI use?

If you have built anything against WordPress in the last decade, your instinct on hearing about MCP is reasonable: we already have a REST API, why do we need another way in? The honest answer is that MCP is not a replacement for the REST API — a good MCP server calls it — but it solves three problems the REST API was never designed for, all of which appear the moment a language model is the caller.

This is a developer-facing comparison: what each layer does, where the boundary sits, and when you should build against which.

What the REST API gives you

The WordPress REST API is a well-understood HTTP interface: predictable routes, standard verbs, JSON in and out, authentication via cookies, application passwords or JWT. It is excellent at what it was designed for — a program that already knows what it wants, written by a developer who read the docs.

Its assumptions are worth naming, because they are exactly what breaks with an AI caller:

• The caller knows the routes in advance.
• The caller knows which fields matter and what values are legal.
• Authorisation is coarse — a capability, not a per-operation scope.
• Nothing records intent; the access log knows a POST happened, not why.

What MCP adds on top

MCP is a layer above, and it adds precisely the three things a model needs:

1. Discovery. The client asks the server what it can do and gets back tools with descriptions and schemas. The model does not need to have been trained on your routes; it can find out at run time. This is the single biggest difference.
2. Semantic typing. A REST endpoint's schema describes data shapes. An MCP tool's description explains purpose — when to use it, what it does, what it will not do — in language the model reasons about.
3. Governed execution. Scopes per connection, an approval step before writes, and an audit log of intent and result. The REST API has none of this natively; you would build it yourself.

Everything else is transport detail. Under the hood, the tool call usually becomes a REST or plugin-API call — which is exactly what you want, because that path is battle-tested and respects plugin logic.

Side by side

• Caller. REST: your code, which knows the routes. MCP: a model that discovers them.
• Contract. REST: documented routes and JSON schemas. MCP: tools with schemas plus natural-language descriptions.
• Auth. REST: user capabilities via cookie, app password or token. MCP: the same underneath, plus per-connection scopes.
• Safety net. REST: whatever you build. MCP: approval gate, draft mode, audit log as part of the server.
• Best at. REST: deterministic integrations, headless front ends, webhooks. MCP: exploratory and multi-step work where the plan depends on what you find.

When to use which

A simple rule that has held up in practice: if you can write the sequence of calls in advance, use REST. If the sequence depends on what you find when you look, use MCP.

• Use REST for: a headless front end, a nightly sync between two systems, a webhook handler, anything with a fixed contract and a service-level expectation.
• Use MCP for: audits, backfills, migrations, content operations, one-off bulk edits, anything where a human is in the loop deciding what to change.
• Use both: commonly the right answer. MCP for the humans-plus-agent work, REST for the machine-to-machine plumbing.

You can, and people do. Three problems appear quickly:

1. Route hallucination. Without discovery, the model guesses routes and parameters from training data — which was true for some WordPress version, on some site, with some plugins. Failures are confidently wrong rather than clean.
2. All-or-nothing auth.
3. No plan step. A model with credentials and a POST route can act before you see the intent. The approval gate is not a nicety at 500 records.

Each is solvable by hand. Solving all three, per site, for every plugin you touch, is exactly the work an MCP server does for you.

What this means if you build plugins

If you maintain a plugin, the pragmatic path is to keep your REST API as the implementation and expose typed MCP tools that call into it. Two consequences worth planning for:

• Tool descriptions are part of your public interface now. A vague description makes a model misuse a good tool.

For a concrete example of that shape at scale — 190+ tools across core and 45+ plugins — see the full ability reference.

FAQ

Does MCP replace the WordPress REST API?

No. MCP sits above it and typically calls it (and plugin APIs) underneath. It adds discovery, semantic typing and governance — the three things a language model needs and the REST API was not designed to provide.

Can't I just give an AI my REST API credentials?

You can, but you get route hallucination, all-or-nothing permissions and no plan-before-write step. Those are the exact gaps an MCP server closes.

Which is faster, REST or MCP?

REST, marginally, since MCP adds a discovery and validation layer. The difference is irrelevant for the work MCP is used for, where the bottleneck is model reasoning and human review, not HTTP.

When should a developer prefer REST?

Whenever the sequence of calls is known in advance: headless front ends, scheduled syncs, webhooks, anything with a fixed contract and uptime expectations.

Should my plugin expose MCP tools?

If people manage your plugin's data as part of their workflow, yes. Keep the REST API as the implementation, expose narrow typed tools on top, and write descriptions carefully — they are now part of your public interface.

Is MCP secure compared to the REST API?

It adds security rather than replacing it: the same WordPress authentication underneath, plus per-connection scopes, schema validation, an approval gate and an audit log.