MCP, WebMCP or the REST API: which should your WordPress site use?

There are now three ways for an AI agent to work with a WordPress site, and they are easy to mix up. The REST API has been in core for years. MCP reaches WordPress through the Abilities API and the MCP Adapter plugin. WebMCP is the new one, where a page in the browser tells an agent what it can do.

The short answer: they are not rivals, because each one serves a different agent. Use the REST API when an agent has to get real work done on your site today. Use MCP when you want a small set of well-described jobs that any MCP client can find and call. Use WebMCP when the agent is a visitor in a browser, using your public pages.

What is the difference between MCP, WebMCP and the REST API on WordPress?

The difference is where the agent sits and what it is allowed to touch. Put simply:

• REST API. The agent talks to your server over HTTP, at /wp-json/, and signs in as a WordPress user, usually with an Application Password. It can do anything that user can do through any route WordPress or your plugins register.
• MCP. The agent also talks to your server and also signs in as a WordPress user, but it only sees abilities: named jobs, each with a description, input and output schemas and a permission check. The MCP Adapter presents the abilities marked public to any client that speaks the Model Context Protocol.
• WebMCP. The agent runs in the visitor’s browser. Your page registers tools with document.modelContext.registerTool(), and the agent calls them inside that page, in the visitor’s own session. It never gets a password for your site.

The WordPress AI team draws the same line. Its post on AI plugin 1.5.0 says MCP Access exposes server-side abilities to external agents, while WebMCP focuses on interactions within the browser itself.

Which one gets more done for an AI agent today?

The REST API, by a wide margin. In October, Andy Peatling ran two coding agents through 21 everyday requests from site owners, such as adding a page with opening hours, once through the MCP Adapter and once through the REST API. In his write-up on the adapter’s GitHub, agents completed 0% of the requests through the adapter and 79% through the REST API.

The reasons he gives are about the default setup, not the protocol:

• Connecting needed an Application Password plus a Node proxy or a hand-built auth header, and claude.ai and ChatGPT could not connect at all.
• The core abilities only read, so nothing could be changed. In 19 runs the agent sent the owner looking for a setting that doesn’t exist.
• Owners could not see in wp-admin what was connected or what had changed.

The telling result: a trial bridge plugin that added read and write abilities on top of the adapter went from 0% to 86% (12 of 14 runs) on a smaller set of 7 requests, level with the REST API on the same requests. The two misses were the contact form request, because that forms plugin’s abilities were not exposed over MCP. So the gap is the abilities, not MCP itself. Peatling’s follow-up issue, “MCP adapter: 0% to 100%”, plans write abilities for content, media and settings, and the AI 1.5.0 post lists content create, update and delete abilities as planned work, not shipped.

I go into the benchmark and what it means for MCP on WordPress in Should your WordPress site have an MCP server?

When should you use the REST API for an AI agent?

Use the REST API when you are the one directing the agent and you need the job done now: a coding agent cleaning up drafts, a script checking for posts without excerpts, a bulk fix on a staging copy. It needs no plugin, and agents already know it well.

The catch is scope. An Application Password carries the full capabilities of its user across the whole REST API. There is no setting that limits one password to one route. So the user is the boundary, and this is the setup I’d use:

1. Create a dedicated user for the agent, never an administrator. Give it the lowest role that can do the job, such as Author or a custom role. It worked if you can sign in as that user and only see what it should see. My post on limiting WordPress AI by role covers custom roles.
2. Create an Application Password for that user under Users, Profile, Application Passwords, and name it after the agent and the job. It worked when the password appears in the list with that name.
3. Test a read-only call first, from the command line. It worked when you get back JSON with your drafts, and a 401 if you change one character of the password.

curl -u "ai-agent:abcd efgh ijkl mnop qrst uvwx" \
  "https://example.com/wp-json/wp/v2/posts?status=draft&per_page=5&_fields=id,title,modified"

4. Revoke the password when the job is finished. It worked when the same curl call returns a 401.

WordPress only offers Application Passwords over HTTPS, unless the site’s environment type is set to local.

When is MCP the better choice for a WordPress site?

MCP is the better choice when the same jobs come up again and again and you want them described once, in a form any MCP client understands. Instead of hoping an agent finds the right route among hundreds, you give it a short list of abilities that each do one thing.

The pieces are all public. The Abilities API has been in core since WordPress 6.9. The MCP Adapter plugin, version 0.7.1 from October 15, reports more than 60,000 active installs on WordPress.org. Its default server offers three tools, to discover abilities, get information about one, and execute one, and only abilities marked public are reachable. The AI plugin’s 1.5.0 release added an MCP Access experiment that installs the adapter and adds a Tools, MCP Access screen where you can see your abilities and choose which ones agents get.

What I’d do before building:

1. List the three to five jobs you would hand an assistant every week. If you can’t name three, MCP can wait.
2. Write each as an ability with a clear description, a schema and a permission callback, starting read-only. How to build a custom MCP server for WordPress walks through it.
3. Connect a client on staging with the same dedicated user you would use for the REST API. It worked when the discover tool lists your abilities and nothing else you didn’t expect. If it doesn’t, the common MCP Adapter errors are the place to start.

MCP uses the same WordPress user and the same Application Password, so it is not a safer door by itself. What it adds is a narrower, described menu. That narrowness is also why the default setup scored 0%: a menu with no write jobs on it can’t do write jobs.

When does WebMCP make sense instead?

WebMCP makes sense when the agent is acting for a visitor, not for you. Someone asks their browser’s assistant to fill in your quote form, and your page tells that assistant which tools exist and what each one needs, so it doesn’t guess from the layout.

WebMCP still runs in Chrome behind a flag or an origin trial, the spec has changed several times this year, and the declarative form attributes were taken out of the spec on October 8. If you added WebMCP code months ago, check it against what changed in the WebMCP API. To start from scratch, making your WordPress site agent-ready with WebMCP has the steps.

Because WebMCP tools run in the visitor’s session, they can only do what that visitor could already do by clicking. That makes it the lowest-risk of the three for public jobs, and the wrong tool for anything that needs admin access.

How do you decide which one your site needs?

Decide by asking who the agent works for and what it has to change. These are the questions I’d run through:

• The agent works for you and the job is one-off or urgent: REST API, with a dedicated user and a password you revoke afterwards.
• The agent works for you or your team and the job repeats every week: MCP, with abilities you wrote for those jobs, tested on staging.
• The agent works for a visitor on your public pages: WebMCP, on the one or two forms or searches that matter.
• You have no staging site and no one to review code: keep your REST API healthy and wait on the other two.

Whatever you choose, don’t block the REST API with a security plugin without knowing what breaks. The adapter’s endpoint is a REST route too, and the block editor depends on the REST API.

If you only do one thing this week, create the dedicated agent user and run that read-only curl call. It is the base for both the REST API and MCP, and it shows you exactly what an agent signing in as that user can see.