WordPress 7.0 is close, and the recent reporting on WordPress AI Features shows the architecture moving out of the experimental bucket and into infrastructure. If you read the weekly contributor summaries, you already know the decisions being made right now will shape how AI agents talk to our sites for the next decade.
I have watched enough core cycles to expect a mess right before a major release. This one is different. The team is being open about reduced contributor availability, and instead of stalling they are moving ahead with “reversible decisions,” which is a tactic worth stealing whenever your own roadmap gets squeezed.
The MCP adapter goes standalone
The biggest structural change discussed this week is how the Model Context Protocol (MCP) adapter gets shipped. There was earlier talk about baking it into core, but that is settled now: it will be a standalone WordPress.org plugin.
Two things make that the right call. The adapter can iterate on its own schedule instead of waiting on the Core release cycle, and dependency management stays simpler. Shipping through the official plugin repository means developers use install workflows they already have, and sites nowhere near needing AI “abilities” do not get saddled with the dependency.
I went deeper on where these WordPress AI Features are heading in an earlier post on WordPress 7.0 AI Features and the MCP Interop.
Registering abilities the right way
The mistake I keep running into is developers hand-rolling their own AI interfaces. The Abilities API exists so you can register your functions and let the MCP adapter find them. Here is what registering a custom ability looks like. Watch the public meta flag, because without it nothing shows up.
<?php
/**
* Register a custom ability for the WordPress AI ecosystem.
*/
function bbioon_register_custom_ai_capability() {
// Check if the Abilities API is available
if ( function_exists( 'register_ability' ) ) {
register_ability( 'bbioon/process-order-logic', [
'label' => __( 'Process Specialized Order', 'bbioon' ),
'callback' => 'bbioon_handle_ai_order_logic',
'meta' => [
'public' => true, // Makes it discoverable by MCP
],
] );
}
}
add_action( 'init', 'bbioon_register_custom_ai_capability' );
/**
* The callback function executed by the AI client.
*/
function bbioon_handle_ai_order_logic( $args ) {
// Logic for processing order goes here
return [ 'status' => 'success', 'message' => 'Order logged.' ];
}Working around the contributor gap
Velocity is the part nobody wants to bring up. Several leads are booked on other priorities for the next month, and a gap like that normally wrecks a release candidate. The team dealt with it by handing decision authority to the maintainers who are actually around. Work keeps moving and every choice gets documented. Anything genuinely irreversible waits until everyone is back.
On the UI side, the WordPress AI Plugin 0.8.0 release is still on track for April 23rd, with content resizing and request logging as the headline additions. Boring features, and usually the ones that decide whether a system survives production.
If keeping up with WordPress AI Features is eating your dev hours, I can take it off your plate. I have been working with WordPress since the 4.x days.
What this means if you ship plugins
The run-up to WordPress 7.0 is bumpy, but the engineering under it holds up. Pulling the MCP adapter out and keeping decisions reversible means WordPress AI Features is not resting on choices nobody can undo later. So if you ship plugins, go through your code now and mark the functions that should become abilities, then be ready when the standalone adapter lands.
