Should your WordPress site have an MCP server?

WordPress has moved a step closer to shipping with MCP built in. The Make WordPress AI team’s weekly summary for 21 October says Matt Mullenweg has approved making MCP “a de facto part of the WordPress experience”, with WordPress 7.3 discussed as a possible target and no release commitment. A few days earlier, Andy Peatling’s agent benchmark found that coding agents completed none of 21 everyday site-owner requests through the MCP Adapter, against 79% through the REST API.

So should your site have an MCP server? If you have jobs that repeat and a developer who can write abilities for them, yes: start now, read-only, on staging. If you run a brochure site, wait. The default setup doesn’t do much yet, and the plan to change that is still being worked out.

What is an MCP server on a WordPress site?

An MCP server is the doorway an AI assistant uses to do things on your site, and on WordPress it comes from two pieces. The first is the Abilities API, in core since WordPress 6.9. It lets WordPress and plugins describe what they can do: each ability has a name, a description, input and output schemas, and a permission check that runs before anything happens.

The second is the MCP Adapter, a canonical plugin on WordPress.org. Version 0.7.1 came out on October 15. It takes those abilities and presents them to assistants such as Claude through the Model Context Protocol.

The adapter’s default server doesn’t list every ability as its own tool. It offers three: one to discover abilities, one to get information about an ability, and one to execute it. The assistant asks what’s available, reads the details, then calls the one it needs. Only abilities marked public show up there, and each plugin decides which of its abilities to mark public, so check what a plugin exposes before you connect an assistant. WooCommerce 11.3, due in the week of November 9, marks its product and order abilities public, and the adapter’s default server exposes them.

The in-browser counterpart, where a page tells an AI agent what its forms do, is WebMCP on forms.

What changes if MCP becomes part of WordPress by default?

The direction is agreed, but the shape isn’t. The weekly summary is careful here: making MCP part of the WordPress experience doesn’t necessarily mean moving the whole adapter into core. The options on the table were bundling the plugin with WordPress, enabling it through core interfaces, or building specific capabilities into core. The Repository reports that, according to Jason Adams, Matt’s one request was to throw everything at avoiding new vulnerabilities.

Here’s what is still open:

• How it ships: the proposal names a direct merge or a bundled approach, and doesn’t choose yet.
• How assistants sign in. The proposal plans to map out OAuth during 7.2 and aims to implement it in core for 7.3.
• When. An October 28 proposal from the AI team names WordPress 7.3 as the target and uses 7.2 to lay the groundwork. It says inclusion depends on technical readiness, security and normal core review, so this is a target, not a promise.

Closer in, WordPress 7.2 is in beta and due on December 8. It brings core abilities that read content, users and settings, and none of them can change anything.

For a site owner, the practical change is that an assistant may one day connect to a WordPress site without anyone installing a plugin first.

Why does a default WordPress MCP setup do so little today?

Because out of the box, the abilities an assistant can reach mostly read things. They can’t change them. In Andy Peatling’s benchmark, Claude Code and Codex each worked through 21 everyday site-owner requests, both through the MCP Adapter and through the REST API. Through the adapter they completed 0%. Through the REST API with an Application Password, 79%.

His write-up on the adapter’s GitHub names the causes:

• Connecting was hard: an Application Password plus a Node proxy or a hand-built auth header. Claude.ai and ChatGPT couldn’t connect at all, and there’s no OAuth yet.
• Core abilities are read-only, so pages, posts, photos and settings couldn’t be changed.
• In 19 runs, the agent sent the owner looking for a setting that doesn’t exist.
• A forms plugin’s abilities weren’t exposed over MCP, so the contact form request failed.
• The default server lists only three tools, by design, which limits what an agent finds.
• Setup errors, conflicting copies of the adapter bundled inside other plugins, and nothing in wp-admin showing what was connected or what had changed.

Read that carefully before deciding MCP on WordPress doesn’t work. The benchmark measured what you get out of the box: the adapter plus the abilities WordPress ships with. It wasn’t a test of a site where a developer has written abilities for the jobs that site needs.

A trial “bridge” plugin, which let the adapter call REST routes as the connected user, took a smaller set of 7 requests from 0% to 86% (12 of 14 runs). The REST API scored the same on that sample. Work to close the gap now has its own issue, which plans write abilities for content, media, settings and users. If you’ve hit setup errors yourself, I’ve collected the common ones in MCP Adapter errors and how to fix them.

What makes a WordPress MCP server actually useful?

Abilities that do real jobs for your site, described clearly, are what close the gap. The benchmark’s own results page makes the point: with core write abilities for pages, posts, settings and media uploads, it estimates the adapter could handle 17 of the 21 requests instead of 3.

You don’t have to wait for core. A custom ability is a small piece of plugin code, and the parts that matter most are these:

• A description written for the assistant: what it does, when to use it, what it won’t do. Agents in the benchmark invented settings. Clear descriptions leave less room to guess.
• Input and output schemas, so WordPress rejects bad input before your code runs.
• A permission check that asks WordPress whether the connected user can do this, every time.
• Annotations that say whether it’s read-only, destructive or safe to repeat.

Pick jobs that repeat: list drafts that haven’t been touched in a month, find products missing a short description, create a draft post from a set of notes. Jobs like that are narrow, easy to test and easy to check.

The developer still owns the design. When I build a plugin, AI helps me write it faster, but deciding which abilities exist, what they can touch and how they fail is architecture. That needs a person who reviews it, and I test the result end to end with Playwright before trusting it. More on that split in Is AI bad for developers?

Ready to build one? How to build a custom MCP server for WordPress walks through the whole thing: abilities, the adapter, a custom AI agent role, and an end to end test.

Who should build a WordPress MCP server now, and who should wait?

Build now if your site has repeat work and someone who can write and review code. That usually means:

• Sites with repeat content or catalogue jobs, such as regular publishing, tagging or product data upkeep.
• Teams with a developer who can write abilities, test them and keep them up to date.
• Agencies looking after many WordPress sites, where one well-tested abilities plugin can serve several of them.

Wait if you run a brochure site that changes a few times a year, or if you have no staging site or no developer to check what the assistant can touch. The effort won’t pay back yet.

In the meantime, a few things help either way:

• Keep your REST API healthy. It’s the route agents complete tasks through today, so don’t let a security plugin or a broken route block it without knowing what breaks.
• When you do try it, start read-only and on staging.
• Create a dedicated low-privilege user for any AI connection.

How do you keep a WordPress MCP server safe?

Treat the assistant like a new team member on day one: its own account, the fewest permissions that work, and nothing goes live without a person. These are the rules I’d follow:

1. Give it a dedicated user with its own role. Never connect as an administrator. I explain how to limit WordPress AI features by role.
2. Know what an Application Password is. It has no scope: it carries the full capabilities of its user across the whole REST API, not just the MCP endpoint. Today the user’s role is the only real limit, so revoke the password when you stop using it.
3. Start read-only. Let the assistant look before it touches anything.
4. When you add writes, save drafts. An ability can create or edit a draft, but it doesn’t publish.
5. A person approves. Someone reviews the draft in wp-admin and publishes it, with revisions kept so any change can be undone.

These rules matter more if MCP arrives by default, because the question of who can connect will reach sites whose owners never thought about it.

The default install isn’t the ceiling. What an assistant can do on your site comes down to the abilities someone writes for it and the permissions you give it. When you’re ready, start with the step-by-step build guide.