If you have been following the track leading up to WordPress 7.0, you know the WordPress Core AI work is moving fast, maybe faster than some production environments can absorb. Last week’s contributor meeting made the direction clear: less “cool experiment,” more “don’t break the site.” After 14 years of cleaning up behind experimental features, I read that shift as necessary and a bit overdue.
The standalone MCP adapter
The biggest technical pivot discussed was the decision to ship the MCP (Model Context Protocol) adapter as a standalone plugin on WordPress.org. Decoupling it from the main AI plugin isolates the translation layer that lets AI agents talk to WordPress, and that is the right call. If you have not been following along, the MCP adapter bridges the Abilities API to the Model Context Protocol specification.
In practice, your custom abilities will soon be discoverable by any MCP-compliant client, Claude Desktop and Cursor included, without you writing a custom bridge every time. It also adds a new maintenance surface, and the team is still untangling who owns the WordPress Agent Skills work as opposed to the core adapter logic.
Security hurdles in WordPress Core AI
I have debugged my share of race conditions and transient bugs, but security is where AI integrations usually fall over. The item worth watching this week is the “Connector Approval Experiment,” meant to stop a random plugin from hijacking a user’s OpenAI or Anthropic connection without explicit permission.
If you are building custom integrations, my earlier take on why connector approval is the next big dev hurdle is worth a read. The UI is the easy part. The hard part is a trust layer, which the current WordPress hook system does not have.
Refactoring the Abilities API
The team is also refining “slug fragments” for the Abilities API. That sounds like minor polish, but it matters for roadmap visibility. Without consistent slug management, identifying and prioritizing specific AI capabilities across different themes and plugins gets painful fast. I went further into how this affects your 7.0 readiness in these insights for WordPress 7.0 AI features.
<?php
/**
* Concept: Registering an Ability that the MCP Adapter can expose.
* This is the "correct" way to play with the upcoming 7.0 AI stack.
*/
add_action( 'init', function() {
if ( ! function_exists( 'register_block_editor_ability' ) ) {
return;
}
bbioon_register_custom_ai_skill();
} );
function bbioon_register_custom_ai_skill() {
// This is where the slug fragments come into play for 7.0
register_ability( 'bbioon/v1/get-post-analytics', [
'description' => __( 'Fetches engagement data for AI analysis.', 'bbioon' ),
'permission' => 'edit_posts',
'callback' => 'bbioon_fetch_analytics_data',
] );
}
Why polishing comes first now
WordPress Core AI 0.9.0 is scheduled for next week, and 1.0.0 could land just before the WordPress 7.0 release on May 20. The team also agreed that “polishing existing functionality is currently more important than introducing new experiments,” which is the sentence I was hoping to read. Compatibility testing against heavyweights like Elementor, ACF and Yoast is already underway.
If this WordPress Core AI work is eating your dev hours, I can take it off your plate. I have been wrestling with WordPress since the 4.x days.
What to do before May 20
Do not wait for May 20 to start testing. With the MCP adapter split into its own plugin, you can build Agent Skills now without bloating your core site logic. Put your attention on security, particularly how your site handles connector approvals, and on making sure your custom hooks do not conflict with the new Abilities API standards. WordPress is heading somewhere that looks less like a CMS and more like a platform agents drive directly. Refactoring for that now costs less than debugging it later.
