Running a WordPress MCP server is no longer a weekend experiment. With the Abilities API in core since WordPress 6.9 and the MCP Adapter released as an official package, any WordPress install can expose its own functions for an AI agent to consume. What separates this from everything that came before is that there is now a shared standard — and a permission model built on real WordPress capabilities rather than on instructions written into a prompt.
This article covers what changed, how the pieces fit together, and above all what needs to be in place before you switch this on for a production site.
What MCP is, and why it reached WordPress
The Model Context Protocol (MCP) is an open protocol that standardizes how an AI application discovers and executes functions in an external system. Instead of every tool inventing its own integration, the agent speaks MCP and the system on the other side exposes tools (executable functions) and resources (data sources).
For WordPress, this solves a long-standing problem. Connecting an AI to a site through the REST API was always possible, but every project rewrote the same glue: authentication, discovery, input validation, error handling. The result was fragile integrations that were hard to audit and impossible to reuse across clients.
The Abilities API: the foundation that shipped in core
The Abilities API landed in core with WordPress 6.9, released on December 2, 2025. It is an abstraction layer for registering site “abilities” — typed, discoverable, executable functions that can be triggered through REST, WP-CLI, the Command Palette, WPGraphQL, or an LLM call.
Every ability defines four required parts:
'name' => 'my-agency/list-pending-orders',
'input_schema' => [ /* typed input */ ],
'output_schema' => [ /* typed output */ ],
'permission_callback' => function () { /* require the right capability */ },
'execute_callback' => function () { /* do the work */ },
Core ships three abilities out of the box — core/get-site-info, core/get-user-info and core/get-environment-info — which serve as examples of the format rather than as features in their own right.
The part that tends to get overlooked: the input and output schemas are not paperwork. They are what lets the agent understand which functions exist and which arguments they take, without anyone describing the API in natural language inside the prompt.
The MCP Adapter: the bridge between abilities and agents
The Abilities API does not speak MCP on its own. That translation is handled by the MCP Adapter, an official WordPress project package distributed through GitHub Releases as part of the AI Building Blocks initiative.
The adapter converts registered abilities into MCP primitives and exposes three discovery tools:
mcp-adapter-discover-abilities— lists what existsmcp-adapter-get-ability-info— details a specific abilitymcp-adapter-execute-ability— runs it
This layered design is deliberate. The agent discovers, inspects, and only then executes, instead of being handed an enormous catalog of functions on first contact.
Nothing is exposed by default. An ability only becomes visible to the agent when it is explicitly marked:
'meta' => array( 'mcp' => array( 'public' => true ) ),
Two transports, two scenarios
STDIO runs the MCP server as a WP-CLI subprocess, with no network exposure:
wp mcp-adapter serve --server=mcp-adapter-default-server --user=admin
This is the option for local development and for cases where you own the machine WordPress runs on.
HTTP exposes the server at /wp-json/mcp/mcp-adapter-default-server, authenticating with application passwords over Basic Auth. Because those credentials travel base64-encoded, HTTPS is mandatory — not advisable, mandatory. After initialization, every request must carry an Mcp-Session-Id header, and the session expires after 24 hours of inactivity.
The security catch you need to know about
Here is the detail that decides whether this integration is safe or a problem waiting to happen: the default transport permission check is is_user_logged_in().
Read that again. If you do not pass an explicit permission callback on the transport, any logged-in user — including a Subscriber — can reach your MCP server. On a brochure site with registration closed, that barely matters. On a site with open signup, a membership area, or WooCommerce, the exposed surface is far larger than “deny by default” suggests.
The good news is that the per-ability permission model is solid. Each ability’s permission_callback runs on every call, binding the agent to real WordPress capabilities. An agent cannot talk itself into permission it does not have.
The minimum checklist before enabling MCP on a client site:
- A dedicated, least-privilege user. Never your admin account.
- An explicit permission callback on the transport. Do not rely on the logged-in default.
- No
__return_trueon abilities that write, delete, or change settings. - HTTPS everywhere, no exceptions, because of the application passwords.
- Read-only over HTTP. Write operations stay on STDIO or behind an admin-only server.
- Observability logging, so unexpected agent behavior is visible.
- Rotate application passwords when someone leaves the team — there is no per-client revocation.
What is still missing
The MCP Adapter is pre-1.0. In practice that means manual updates, per-site exposure configuration, and a real chance of behavior changes between versions.
But the bigger gap is not code maturity — it is environment. The adapter executes commands. It does not manage staging, take snapshots, or roll back. The question no adapter answers on its own is what happens when the agent gets it wrong — and agents do get it wrong. Without staging, automated backups, and a tested path back, putting MCP writes into production means handing that risk to the client.
That is exactly why MCP on WordPress is less a plugin decision than an infrastructure one.
Where to start
If you run a handful of sites, the sensible play in 2026 is to start read-only: expose abilities that query — order status, content metrics, site health — connect them to an MCP client, and get comfortable with the permission model before letting any agent write.
If you operate dozens of sites, the calculation changes. There the value is in standardizing a shared set of abilities across projects, with a restricted transport, centralized logging, and a staging environment that actually works.
At Amicatek, WordPress is what we do, and the Abilities API is the most consequential core change in years for anyone serious about AI. If you want to work out what makes sense to expose on your site — and how to do it without opening the wrong door — talk to us. We review your environment and design the implementation alongside your team.