The WordPress MCP Adapter is the official package that lets an AI agent talk to WordPress abilities over the Model Context Protocol. It is not a rival to Agent Abilities for MCP. Agent Abilities is built on top of the Adapter: same Abilities API, same MCP transport, no transport of its own. This page exists because “wordpress mcp adapter” is a term people search and AI engines cite constantly, and there was no honest answer anywhere comparing the bare Adapter to a governed product built on it. If the concept itself is new to you, our explainer on what a WordPress MCP server is covers the basics first.
What is the WordPress MCP Adapter, and do I need anything else?
The WordPress MCP Adapter is a free, official package from the WordPress Core AI team that converts registered WordPress abilities into MCP tools, resources, and prompts. On its own it has no admin screen, no per-ability toggle, no audit log a site owner can read, and no rate limiting: those are things a plugin built on top of it, such as Agent Abilities for MCP, adds. If your active plugins do not already register abilities marked public, installing the Adapter alone exposes very little.
Takeaways:
- The Adapter is infrastructure, not a finished product. A developer wires it up in PHP; a site owner does not get a settings screen from it alone.
- It has no admin UI, no site-owner-facing audit log, no rate limiting, and no IP allowlist, confirmed absent across its own README, readme.txt, and two official WordPress.org blog posts.
- Agent Abilities for MCP is not a competing MCP framework. It is a 153-ability catalog, an admin UI, and a governance layer that sits on top of the same Adapter.
- Where the Adapter genuinely has more to offer is developer flexibility: custom transports, multiple named servers, and MCP resources and prompts, not just tools.
- If you are a site owner who wants to let an agent in without writing PHP, the Adapter alone is not the whole answer. If you are a plugin developer registering your own abilities, the Adapter is the right layer to build against directly.
What the Adapter actually is
The MCP Adapter is part of the AI Building Blocks for WordPress initiative, credited to the WordPress Core AI team and published on GitHub under the WordPress organization. Its own README describes it plainly: it “bridges the WordPress Abilities API with the Model Context Protocol,” and once your code registers an ability, “you are one step away from letting an AI agent use them” (developer.wordpress.org, published 4 February 2026).
It is distributed primarily through Composer (composer require wordpress/mcp-adapter), or as a manual plugin install from a GitHub release zip.
It does not have its own listing in the WordPress.org plugin directory. Requesting wordpress.org/plugins/mcp-adapter/ redirects to the directory’s search page rather than a listing, and the WordPress.org Plugin API itself returns “Plugin not found” for the slug mcp-adapter.
What it does, in its own words, is real and useful:
| Capability | What the Adapter’s own docs say |
|---|---|
| Transports | HTTP (REST, under /wp-json/mcp/) and STDIO (WP-CLI, wp mcp-adapter serve), plus a documented interface for custom transports |
| Ability-to-MCP conversion | “Automatically converts WordPress abilities into MCP tools, resources, and prompts” |
| Multi-server management | Developers can create and configure more than one named MCP server |
| Permission model | “Granular, configurable permission checking,” implemented through each ability’s own permission_callback |
| Observability | A metrics-tracking interface (McpObservabilityHandlerInterface) and an error-handling interface, both meant for developers to hook into |
Sources: github.com/WordPress/mcp-adapter README and readme.txt (Requires at least 6.9, Requires PHP 7.4, Tested up to 7.0, Stable tag 0.5.0, released 15 April 2026), and docs/getting-started/README.md in the same repository; the WordPress.org Plugin API (api.wordpress.org/plugins/info/1.2/); make.wordpress.org/ai, “Release announcement: MCP Adapter v0.3.0,” published 24 November 2025. All checked 11 August 2026.
What none of those sources describe, checked across the GitHub README, the readme.txt feature list, the getting-started guide, and both official make.wordpress.org/ai and developer.wordpress.org posts about the project: a wp-admin screen where a site owner switches an individual ability on or off, a call-by-call log a non-developer can read or export, per-minute rate limiting, or an IP allowlist. The getting-started guide shows how an ability becomes an MCP tool, and it is a code change: mark the ability meta.public: true, or list it explicitly in a custom server’s PHP configuration when you call create_server() (docs/getting-started/README.md). There is no equivalent click in wp-admin.
What Agent Abilities for MCP adds on top of it
Agent Abilities for MCP is built on the WordPress 6.9 Abilities API and the official MCP Adapter, with no transport of its own. It is the layer a site owner actually operates: a fixed catalog of 153 governed abilities (83 across WordPress core, 70 across WooCommerce, Advanced Custom Fields, Rank Math, Yoast, and All in One SEO), every one off until you switch it on yourself, plus an audit log you can read, filter, and export without writing a line of PHP.
That catalog ships with the plugin rather than depending on which of your other plugins happen to register public abilities already, which today is still uncommon since the Abilities API itself only landed in WordPress 6.9. Two layers of capability checking sit under every call: a connection only sees the tools its user can run, and WordPress re-checks that user’s capability again before the call executes, independent of whatever any individual ability’s own permission_callback does.
Side by side
| Dimension | WordPress MCP Adapter | Agent Abilities for MCP |
|---|---|---|
| What it is | The official primitive: converts registered abilities into MCP tools, resources, and prompts | A full governed server built on that primitive: a fixed 153-ability catalog, an admin UI, and a governance layer |
| Distribution | Composer, or a manual plugin install from a GitHub release; no WordPress.org directory listing found under its own slug as of Aug 2026 | On WordPress.org, slug agent-abilities-for-mcp, free, GPL |
| Requirements | WP 6.9+, PHP 7.4+, tested up to WP 7.0, stable release 0.5.0 (15 Apr 2026) | WP 6.9+, PHP 7.4+ |
| How abilities become tools | A developer marks meta.public: true in code, or lists the ability explicitly in a server config |
Every ability ships registered but off; you switch each one on from a settings screen, one at a time or by group |
| Permission model | Whatever each ability’s own permission_callback implements, tied to WP capabilities |
Two layers: filtered discovery by the connected user’s capability, plus a re-check before every call, on top of the ability’s own callback |
| Identity | Application Passwords over HTTP (through a separate @automattic/mcp-wordpress-remote proxy), or a --user= CLI flag over STDIO |
OAuth approval in the browser, or an Application Password pointed at a dedicated low-privilege user, with a guided setup screen |
| Audit log | A developer-facing observability and error-handling hook; no documented site-owner screen | Every call, denials included, with the principal, argument keys, and identifiers touched, filterable and exportable as CSV |
| Rate limiting / IP allowlist | Not documented | Optional per-minute rate limit and IP allowlist, both off until set |
| High-risk write protection | Not documented; whatever the ability’s own callback enforces | Nine WooCommerce abilities (refunds, order status, order updates, customer updates, payment gateway settings, coupon and tax rate creation and updates) stay locked behind a separate switch even after you enable them |
| Read-only mode | Not documented | One switch stops anything that writes from being registered as a tool at all, bridged abilities included |
| Transports | HTTP, STDIO, plus a custom-transport interface and multi-server management | Rides the Adapter’s HTTP transport; no custom transport or multi-server management of its own |
| Business model | Free, open source, part of a core initiative; no pricing model | Free on WordPress.org, no paid tier |
Adapter-side facts sourced as cited above, all checked 11 August 2026. Our-side facts are single-sourced from src/data/product.ts.
Where the Adapter genuinely leads
It is the reference implementation. Every WordPress MCP plugin that claims to build on the Abilities API, ours included, depends on decisions made in this one project. Being the official, actively maintained core primitive is a real strength, and it is not something a plugin built on top of it can claim for itself.
Developers get more room to move than our plugin gives them. The Adapter documents a custom-transport interface and multi-server management, so a developer can run more than one MCP server with different ability sets, or write a transport of their own. Agent Abilities for MCP does neither. It rides the Adapter’s HTTP transport and runs as a single server, so if you are building a bespoke integration rather than operating a WordPress site, that headroom is missing.
There is also a scope difference worth naming plainly. The Adapter’s own README lists three MCP primitives it converts abilities into: tools, resources, and prompts. Our own readme, checked directly, describes the catalog only in terms of abilities and tools, with no mention of resources or prompts as a supported shape. That is a documented gap, not a smear.
Where we fall short
We are a dependent, not an independent choice. If the Adapter’s own API changes in a way our plugin has not caught up with yet, that is a risk any product built on core infrastructure carries, and it is worth saying plainly rather than pretending our governance layer sits above it somehow.
Our catalog is fixed, not infinitely extensible. The Adapter lets any developer register any ability they can dream up and expose it however they choose. Ours is real and governed, but it is what we built and maintain: 153 abilities plus a bridge for what your other active plugins register, not a blank canvas.
And if your use case genuinely needs a second MCP server with a different ability set, or a transport other than HTTP, the bare Adapter gives you that. We do not.
Who each one is actually for
If you are a WordPress site owner who wants to let an AI agent read or write your content without writing PHP, the bare Adapter is not the whole answer: installing it alone, with no other plugin registering abilities you want exposed, gets you very little to actually call. That is the gap Agent Abilities for MCP fills, with a catalog you can turn on from a settings screen and an audit log you can actually read.
If you are a plugin developer registering your own custom abilities and want full control over exactly how and when they become MCP tools, resources, or prompts, building directly against the Adapter is the right layer. It is what Agent Abilities for MCP itself does under the hood.
Getting from the bare Adapter to a governed setup
- Install the Adapter, either through Composer or as a standalone plugin, if you have not already. Agent Abilities for MCP requires it and will not run without it.
- Install Agent Abilities for MCP from WordPress.org. It uses the Adapter’s HTTP transport, so there is nothing to configure between the two plugins.
- Open the plugin’s Quick Connect wizard and switch on the abilities you want, starting with reads. Nothing is exposed until you choose it.
- Connect an AI client over OAuth or a dedicated Application Password, and check the audit log after the first few calls so you know what “normal” looks like before you widen access. See connecting a client for the client-by-client steps.
Once connected, a good first prompt to hand your AI client is one that tests governance rather than content, since that is the part the bare Adapter does not give you:
List every action you're currently allowed to take on this WordPress site, grouped by whether each one only reads data or can change something.Against a bare Adapter setup with nothing configured, this will usually come back nearly empty or fail outright, since nothing is exposed until a developer wires it up in code. Against Agent Abilities for MCP, it comes back with exactly the abilities you switched on, nothing more, and the request itself lands in your audit log.
FAQ
Is the WordPress MCP Adapter a plugin I install instead of Agent Abilities for MCP? No. Agent Abilities for MCP requires the Adapter and is built on top of it, not against it. The Adapter is the transport and conversion layer; Agent Abilities for MCP is the governed catalog, admin UI, and audit log a site owner actually operates.
Does the WordPress MCP Adapter have an admin UI or an audit log? No, not as of 0.5.0 (released 15 April 2026). Its README, readme.txt, and two official WordPress.org blog posts describe transports, ability conversion, and a developer-facing observability hook, with no documented site-owner screen for toggling abilities or reading a call log.
Is the WordPress MCP Adapter part of WordPress core? No. As of 11 August 2026 it is distributed separately, primarily through Composer, with a manual plugin install option from a GitHub release. It requires WordPress 6.9 or later and is tested up to WordPress 7.0, per its own readme.txt.
Do I need Agent Abilities for MCP if I already installed the Adapter? If none of your active plugins register abilities marked public, installing the Adapter alone exposes very little for an agent to call. Agent Abilities for MCP ships a 153-ability catalog on top of the Adapter, off by default, so there is something real to turn on. See our governance concepts doc for how the capability checks and audit log work together.
The honest bottom line
The WordPress MCP Adapter and Agent Abilities for MCP are not competitors. The Adapter is the official, well-built primitive that translates WordPress abilities into MCP; Agent Abilities for MCP is a governed product built on it, for the site owner who wants a real catalog, a settings screen, and an audit log without writing PHP. If you are evaluating whether to stop at the bare Adapter or add a layer on top, the honest answer depends on whether you are configuring code or running a site. Full technical detail on how the capability checks and the high-risk lock work sits on our security page; the Abilities API explainer covers the standard both projects build on.