I had a client last year, a big WooCommerce store, who wanted SEO-friendly meta descriptions generated for their 50,000 products. My first instinct was to wire a direct wp_remote_post call to the OpenAI API. Simple enough: hardcode the model, set up a prompt, ship it. It worked for about two weeks. Then the client wanted to test Claude for the better reasoning, and my simple implementation turned into a pile of if/else statements and brittle JSON parsing. Direct API calls are the fast lane to technical debt when it comes to AI for WordPress developers.
The problem was never the AI, it was how we bolt it on. We have treated AI like a third-party widget instead of part of the stack. The 6.9 and 7.0 cycles change that. There is finally a standardized way to talk to these models without rewriting your logic every time a provider revises its documentation.
The Abilities API
WordPress 6.9 brings the Abilities API. An ability is a new primitive for defining functions that are public-facing and, more usefully, discoverable by AI models. Rather than explaining to an LLM what your custom function does, you register it as an ability with a defined schema. The idea comes out of the Core AI roadmap. Registering one with the standard prefix looks like this:
wp_register_ability( 'bbioon/get-product-data', array(
'description' => 'Retrieves specific product metrics for SEO analysis.',
'input' => array(
'type' => 'object',
'properties' => array(
'product_id' => array( 'type' => 'integer' ),
),
),
'meta' => array(
'mcp' => array(
'public' => true,
'type' => 'tool',
),
),
) );
What you get is not a plain function but a tool an AI can request. The mcp meta key is the important part: it lets external models reach your site’s data through the Model Context Protocol, so you never have to expose a hand-rolled endpoint for it.
Standardizing prompts with the WP AI Client
The WP AI Client SDK, coming in WordPress 7.0, is the piece that matters most for AI for WordPress developers. It wraps the PHP AI Client and gives you a single interface for prompts. If one host supports Anthropic and another supports OpenAI, your code stays the same and WordPress does the routing.
Handling a generation task without caring which model sits underneath looks like this:
$bbioon_prompt = AI_Client::prompt( 'Analyze this product content and suggest three keywords.' )
->using_system_instruction( 'You are a professional SEO consultant.' )
->using_temperature( 0.7 );
if ( $bbioon_prompt->is_supported_for_text_generation() ) {
$bbioon_result = $bbioon_prompt->generate_text();
// Do something useful with the result.
}
What I like here is that you can check for support before rendering any UI. If the environment has no registered provider, the “Generate SEO” button never appears. That is ordinary defensive programming, pointed at models instead of endpoints.
Beyond the chat window
AI in WordPress does not have to mean a chat window. The features that earn their keep are quieter: alt text generated for images in the media library, rephrase suggestions inside a paragraph block. They help without taking over the editor. Build them on the MCP Adapter and the AI Client and a faster model shipping next month costs you nothing in code changes.
API integrations rot faster than most code. If you would rather not maintain a tangle of provider-specific calls someone else wrote, get in touch with my team. We have probably seen your version of it already.
This only works if hosts and developers move together: the more developers ship these features, the more pressure hosts have to provide decent AI infrastructure. Which leaves you with a choice between hardcoding more wp_remote_post calls and building something that survives the next model release.
