The WordPress MCP Adapter is the plugin that turns a WordPress site into an MCP server: it takes the abilities registered on the site, by WordPress core and by plugins, and lets an AI client discover and run them as MCP tools. The project’s own README calls it “the official WordPress package for MCP integration”, and since version 0.7.0, published 2026-10-02, it installs straight from the WordPress.org plugin directory.
What that means in practice: the Adapter ships no AI features and no content tools of its own. What it exposes is whatever WordPress core, plugins or custom site code mark public, and that can be more than you expect. On a WordPress 7.1.2 site with one fields plugin active, its discovery tool listed 51 abilities, five of them permanent deletes. 🔍
This guide covers what the Adapter is today, what happened to Automattic’s original project, what it exposed on a real site, who can connect, how to keep the list narrow, and your options. If MCP itself is new territory, read the plain-English guide to what MCP is in WordPress first, then come back.
What the WordPress MCP Adapter is, and what happened to Automattic’s WordPress MCP
MCP, the Model Context Protocol, is an open standard that lets AI applications call external tools through one common interface. The Adapter is WordPress’s implementation of the server side, in the words of its directory FAQ: “MCP Adapter is the server and transport layer. It does not provide any AI features itself.” WordPress.org publishes it as part of the AI Building Blocks for WordPress initiative.
What it serves comes from the Abilities API, a registry that landed in WordPress core in version 6.9. An ability is one named capability: typed input and output, an optional permission check, and the code that does the work. Core registers a few abilities, plugins register more, and the Adapter turns the public ones into MCP tools, resources and prompts.
Is it the same thing as Automattic’s WordPress MCP? No. That GitHub repository, an earlier Automattic project, is now archived, and its README is blunt: “This repository is deprecated and archived. It is no longer maintained, and it is not the recommended way to add MCP support to WordPress.” The same README names the MCP Adapter as “the canonical plugin and Composer package for MCP integration in WordPress” and points readers to the WordPress.com MCP documentation for current setup.
Installation is routine: Plugins → Add Plugin, search “MCP Adapter”, install, activate. It requires WordPress 6.9 or newer and PHP 7.4 or newer. And after activation? Nothing to click: the admin menu gains no MCP Adapter entry, and on the Plugins screen the MCP Adapter row has no Settings link:
How the Adapter works, in plain words
On the Adapter’s default server, every ability is private by default, and private means invisible to MCP clients. An ability becomes reachable only when it is marked public, either with the general public flag or the MCP-specific one (the MCP flag wins when both are set). The directory FAQ states the rule in four words: “No, exposure is opt-in.”
Here, the AI never gets the abilities themselves as its tool list. It gets exactly three: mcp-adapter-discover-abilities lists what is public, mcp-adapter-get-ability-info fetches one ability’s full schema, and mcp-adapter-execute-ability runs one. On the measured site, tools/list returned those three while 51 abilities sat behind them. The AI discovers, inspects, then executes, so tools/list stays at three schemas however many abilities the site has.
The flow, as a picture:
One more layer matters: listing is not running. Before an exposed ability runs, the Adapter checks its permission callback against the WordPress user the client signed in as. In the FAQ’s words, “permission checks still run against the current user before anything executes.”
What it exposed on a real WordPress 7.1.2 site
On a WordPress 7.1.2 site with MCP Adapter 0.7.0 and Secure Custom Fields 6.9.5 active (2026-10-05), signed in as an administrator over HTTP, the discovery tool returned 51 abilities: 3 registered by WordPress core, 48 by Secure Custom Fields, and nothing from anywhere else.
The core three are core/get-site-info, core/get-user-info and core/get-environment-info, and WordPress marks them public in its own code. Two of them require the manage_options capability, which on a standard site means administrators; core/get-user-info answers any signed-in user with their own profile.
The other 48 are public because Secure Custom Fields says so: its code sets the MCP public flag on the abilities it registers. The set covers the plugin’s own structures (field groups, fields, post types, taxonomies and options pages) from listing and creating to importing, trashing and restoring. Five of them are permanent deletes; one describes itself as: “Permanently deletes an instance of SCF field group. This action cannot be undone.” ⚠️
Just as notable is what is missing: none of the 51 reads or edits posts, pages, media or comments. The Adapter is a window; WordPress core and your plugins decide what is on the other side of it. 👀
Who can use it: credentials, roles and an Editor’s view
Without credentials, nothing gets in: calling the endpoint with no authentication answered 401 and the message “Sorry, you are not allowed to do that.” With credentials, the default HTTP transport asks only for a signed-in user with the read capability, and a filter can raise that requirement.
Signed in as an Editor (that user’s own application password, 2026-10-05), discovery returned the same 51 abilities the administrator saw. With the filter from two sections down in place and one small custom ability of the site’s own made public, discovery showed 19 read-only entries, and each of the 19 was called as that Editor. Two ran: the Editor’s own profile via core/get-user-info and that custom ability. The other 17 answered “Permission denied”, among them the core site-info and environment-info abilities and every Secure Custom Fields list, get and export.
Two ways to connect: HTTP and WP-CLI
Over HTTP, the server lives at /wp-json/mcp/mcp-adapter-default-server. Clients authenticate as a WordPress user, and the standard credential is an application password, created under Users → Profile → Application Passwords. By default, WordPress offers application passwords only on HTTPS sites and in local environments, they cannot be used for traditional logins, and they can be revoked from the same screen. The form, on the measured site:
Clients that only speak STDIO to a remote site can use the @automattic/mcp-wordpress-remote proxy, which runs on your own computer and turns the client’s STDIO traffic into HTTP calls authenticated with those same application passwords. Ready-made configurations for Claude Desktop, Cursor, Claude Code and VS Code live in the WordPress developer blog’s tutorial; it predates the directory listing, so follow its client configs, not its install steps.
On a local site, or any server where you have WP-CLI, the same server speaks STDIO, with no HTTP and no application password involved:
wp mcp-adapter serve --user=admin --server=mcp-adapter-default-serverThe AI then acts as the user named after --user, with exactly that user’s capabilities. In a scripted session piped to that server on the measured site (2026-10-05), tools/list returned the same three tools and an ability executed successfully.
How to keep the exposure narrow
Two small levers do most of the work. 🛡️
Lever one is the account. The developer blog’s security section advises a dedicated user with limited capabilities for MCP access, and read-only abilities for HTTP endpoints exposed over the internet. The Editor account above could run only 2 of the 19 read-only abilities it called.
Lever two is a filter that unpublishes what you don’t want reachable. The Adapter’s documentation confirms the mechanism: an explicit meta.mcp.public set to false opts an otherwise public ability out of MCP. On the measured site, this must-use plugin hid every Secure Custom Fields ability that is not read-only:
/**
* Plugin Name: Limit MCP Abilities
* Description: Keeps Secure Custom Fields' read-only abilities visible to MCP clients and hides the ones that write or delete.
*/
add_filter( 'wp_register_ability_args', function ( $args, $ability_name ) {
if ( 0 === strpos( $ability_name, 'scf/' ) && empty( $args['meta']['annotations']['readonly'] ) ) {
$args['meta']['mcp']['public'] = false;
}
return $args;
}, 10, 2 );Save it as wp-content/mu-plugins/limit-mcp-abilities.php, beginning the file with an opening <?php line.
The before and after, measured 2026-10-05: with the site’s one small custom ability also public, discovery listed 52 abilities; with the filter it listed 19 (3 core, 15 read-only ones from Secure Custom Fields and that custom ability), with zero delete abilities listed. A direct attempt to call a delete anyway came back with Ability "scf/delete-field-group" is not exposed via MCP (mcp.public!=true).
Does the trimmed list hold up in front of a real AI? On 2026-10-05, Claude Code 2.1.289, connected over HTTP with an administrator’s application password and MCP tools only, was asked: “Which abilities can you use on this WordPress site, and can any of them change or delete something? Don’t change anything.” Its reply began:
“I found 19 abilities on this site, and none of them are write or delete operations. Every one only lists, gets or exports something. I only used the discovery and info tools, and I didn’t run any ability.”
It described the Secure Custom Fields entries as “a list, get and export ability for each of” post types, taxonomies, UI options pages, field groups and fields, and flagged that some answers carry sensitive data, such as the admin email address. Read its verdict with some caveats: it checked the metadata of only some abilities, went “by the names and descriptions for the rest”, found two of the Secure Custom Fields schemas “were too long for me to read in this session”, and noted that the “readonly” and “destructive” labels “are set by the plugins themselves”. The filter above trusts the readonly one.
Anything the AI can read can steer it: comments, form entries and imported content can all carry hidden instructions. Prompt injection is entry LLM01 in OWASP’s Top 10 for LLM applications, including the indirect kind that arrives inside external content such as websites or files. A read-only list and a low-privilege MCP user apply OWASP’s own least-privilege advice to your site.
💡 PRO TIP: a plugin update can add public abilities without asking, the same way Secure Custom Fields publishes its own. Re-run discovery after updates, and remember the filter above only covers the plugins it names.
Limits worth knowing
- It’s pre-1.0 software. The 0.7.0 release notes list breaking changes, but they land on code that extends the adapter, and the same release deprecates bundling it as a Composer library: “Install the plugin instead.” On compatibility, 0.7.0 adds MCP 2026-07-28 and still connects clients that ask for 2025-06-18.
- There are no screens of its own. What is public and what gets filtered live in code; HTTP credentials are managed in WordPress’s own Application Passwords section. No PHP in your toolbox? The next section is your stop.
- Ability schemas can be huge. The four Secure Custom Fields ability-info text results measured on 2026-10-05 ran from 85,467 to 122,584 characters each; the core site-info ability’s result was 1,651 characters. Verbose plugins make the AI work harder, one more argument for a short public list.
Your options if you want ready-made tools
The Adapter is a foundation: if the goal is an AI that helps run your site, one more piece is needed. Three routes get you there. 🧭
1. Build on the Adapter. Register your own abilities (a developer task) or install plugins that register theirs, and keep the public list narrow as shown above. Best when you want exactly your tool set.
2. Use WordPress.com’s built-in MCP server. WordPress.com includes a built-in MCP server on all paid plans (free sites get it for the first 30 days after creation), and self-hosted sites connected through Jetpack with a Jetpack AI or Jetpack Complete plan use the same server. Authentication is OAuth 2.1 through the browser, so there are no application passwords to manage. Best when your sites already live on, or connect to, WordPress.com.
3. Install a plugin that ships its own tools and screens. Easy MCP AI is one: free 🆓, with 280+ tools spanning content, media, WooCommerce, SEO fields and analytics, connections over OAuth 2.1 or API tokens, and per-ability switches under Easy MCP AI → Tools → Abilities (from version 2.0.1, on WordPress 6.9+, a fresh install starts with the non-destructive ones already enabled). Its audit log records every MCP tool call. Easy MCP AI is made by Themeisle, the company behind this blog. Best when you want screens instead of code.
For the rest of the field, the ThemeIsle roundup of WordPress MCP server plugins compares the options, and for a click-by-click setup with a plugin, follow the guide to connecting AI assistants to WordPress.
Final thoughts 💭
- The WordPress MCP Adapter is the current, WordPress.org-published way to expose a site’s abilities as MCP tools; Automattic’s older project is archived and points to it.
- What it exposes is whatever core and plugins mark public: on the measured site, 51 abilities, five of them permanent deletes, and nothing for posts.
- Before an ability runs, its own permission check decides: an Editor got “Permission denied” on 17 of 19 read-only abilities.
- With one small custom ability also public, a short filter brought the list from 52 down to 19 read-only abilities, and in a live session Claude Code reported that none of them could change or delete anything; a low-role user then limits what runs.
The shortest path from here: install it, ask the discovery tool what is public on your site, then decide how narrow you want the list. Have you connected an AI client to your WordPress site yet, and which route did you take? Let us know in the comments section below!
FREE GUIDE
4 Essential Steps to Speed Up Your WordPress Website
Follow the simple steps in our 4-part mini series and reduce your loading times by 50-80%. 🚀
