A few months back a client came to me with a problem I now see fairly often. They wanted their AI assistant, a custom Claude setup, to “check stock” and “reorder supplies” from their WordPress dashboard. Someone had already built them a pile of custom REST API endpoints, and it was a mess. The endpoints were so verbose that the AI hallucinated half the time, and the token bill was starting to look like a mortgage payment.
My first instinct was to tighten up the REST responses and filter the JSON output down to the bare essentials. That saved a few pennies and left the real problem untouched. The AI still had no structured idea of what the site could actually do, so it kept guessing. That is when I started looking at the WordPress MCP integration and the official adapter the core AI team is building.
What the MCP Adapter v0.3.0 changes
The Model Context Protocol (MCP) is the part that does the work here. Rather than treating your WordPress site as a dump of raw data, the MCP Adapter treats it as a set of “tools” and “resources”. The v0.3.0 release announcement went up on the WordPress Make blog, and it moves things along for anyone building agentic commerce or AI-driven workflows.
Transport and observability were the weakest part of the earlier versions. When the AI failed to call a function, you were flying blind. v0.3.0 aligns everything with the latest HTTP specifications and, more usefully, improves what you can see passing between the AI agent and the WordPress Abilities API. That is the difference between guessing why a script failed and reading the error. Debugging an AI agent without transport logs is not an experience I would sign up for twice.
Registering abilities the right way
You register your functions through the Abilities API. Below is how I would set up a basic inventory check for the MCP Adapter to expose to an AI agent. Note the prefix on everything, which is standard practice to avoid collisions with other plugins.
<?php
/**
* Registering a custom ability for the MCP Adapter.
*/
add_action( 'wp_ai_register_abilities', function( $registry ) {
$registry->register_ability( 'bbioon/check-inventory', [
'title' => __( 'Check Product Inventory', 'bbioon' ),
'description' => __( 'Returns the current stock level for a specific product ID.', 'bbioon' ),
'callback' => 'bbioon_handle_inventory_check',
'args' => [
'product_id' => [
'type' => 'integer',
'required' => true,
'description' => __( 'The ID of the product to check.', 'bbioon' ),
],
],
] );
} );
function bbioon_handle_inventory_check( $args ) {
$product = wc_get_product( $args['product_id'] );
if ( ! $product ) {
return new WP_Error( 'bbioon_no_product', 'Product not found.' );
}
return [ 'stock_status' => $product->get_stock_status(), 'quantity' => $product->get_stock_quantity() ];
}With that in place, the MCP Adapter v0.3.0 takes the ability and turns it into a tool the AI can discover, so nobody is hardcoding endpoints anymore. The agent knows the tool exists and knows how to call it. It is clean, it scales, and it holds up in practice.
Where WordPress AI integration is heading
The move from raw APIs to the Model Context Protocol is the direction of travel. Version 0.3.0 is about making these connections reliable enough for production rather than for a demo. If you are not using the Abilities API to structure your data, you are making the work harder for yourself and more expensive for your clients.
This stuff gets complicated fast. If you are tired of debugging someone else’s mess and want your site to work with current AI tooling, drop my team a line. We have probably run into it before.
Are you still building custom REST wrappers for your AI projects, or are you ready to move to a standardized protocol like MCP?
