WordPress 6.9 introduced the Abilities API, and the core team presented it as another “clean code” standard. There was more to it than that. The WordPress MCP Adapter, released since, is the plumbing that connects your site logic straight to AI agents like Claude, Cursor and VS Code.
Anyone who read my earlier breakdown of the WordPress Abilities API knows I like standardized schemas. A typed function still does you no good if nothing can find it. The WordPress MCP Adapter handles discovery by implementing the Model Context Protocol (MCP). It tells an AI what the site can do, how to call it, and which permissions each call needs.
The architecture behind the adapter
The useful mental model here is AI as an executor, not a chatbot. Registering an Ability in WordPress means defining a unit of work. The MCP Adapter picks up those registered abilities and wraps them in a protocol external LLMs already speak, mapping each one to an MCP Tool.
If your plugin logic already runs through the Abilities API, you are one array key away from making it callable by an agent. That retires the custom-coded bridge every AI tool used to need in order to reach your database.
Exposing your first ability to MCP
Making an ability discoverable by the default MCP server is a matter of flagging it. New abilities take the meta argument. For Core abilities, such as the one that returns site info, use the wp_register_ability_args filter.
<?php
/**
* Hook into the Abilities registration to flip the MCP switch.
*/
add_filter( 'wp_register_ability_args', 'bbioon_enable_mcp_for_core', 10, 2 );
function bbioon_enable_mcp_for_core( array $args, string $ability_name ) {
$target_abilities = array(
'core/get-site-info',
'core/get-user-info',
);
if ( in_array( $ability_name, $target_abilities, true ) ) {
// This is the magic flag the WordPress MCP Adapter looks for
$args['meta']['mcp']['public'] = true;
}
return $args;
}Connecting your dev tools
The WordPress MCP Adapter supports two transport methods, STDIO and HTTP. Locally, and local is where you want to be while testing this, STDIO through WP-CLI is the steadier of the two. For Cursor or Claude Desktop, point their config files at your local wp binary.
One gotcha catches almost everyone: AI clients read their config at startup. Edit mcp.json or claude_desktop_config.json, see nothing change, and the fix is usually to restart the app. The other one is the --path argument, which has to be an absolute path to the WordPress root or the adapter never finds the environment.
Building a custom MCP server
You will not always want everything piled into the default server. A specialized plugin for a client is a good case for its own namespace. Initialize a custom server on the mcp_adapter_init action.
<?php
add_action( 'mcp_adapter_init', 'bbioon_register_dedicated_server' );
function bbioon_register_dedicated_server( $adapter ) {
$adapter->create_server(
'client-report-server',
'reports-api',
'mcp',
'Client Reporting Server',
'Exposes sales and inventory data to AI agents.',
'1.0.0',
array( \WP\MCP\Transport\HttpTransport::class ),
\WP\MCP\Infrastructure\ErrorHandling\ErrorLogMcpErrorHandler::class,
\WP\MCP\Infrastructure\Observability\NullMcpObservabilityHandler::class,
array( 'my-plugin/get-sales-report' ) // List of abilities
);
}Security and the permission callback
Handing an LLM executable access to your backend is genuinely frightening if you are sloppy about it. The WordPress MCP Adapter acts as a logged-in user, which makes the permission_callback in your ability registration the only thing standing between an agent and your data.
I would create a dedicated AI service user with very narrow capabilities. Never use __return_true on an ability that deletes or updates content. When an AI hallucinates a command, the WordPress capability system should be the thing that stops it cold.
If this WordPress MCP Adapter work is eating your dev hours, I can take it off your plate. I have been wrestling with WordPress since the 4.x days.
The takeaway
Together, the Abilities API and the MCP Adapter change what a plugin is for. We have spent years building interfaces for people; now some of that work is building capabilities for agents. Start with read-only diagnostics, watch how the permission layer behaves, and only then let an AI anywhere near your database.
