We need to talk about the WordPress Core AI initiative. If you’ve been following the track leading up to WordPress 7.0, you know things are moving fast—maybe too fast for some production environments. Last week’s contributor meeting made one thing clear: the focus is shifting from “cool experiments” to “don’t break the site.” As a dev who has spent 14 years cleaning up after “experimental” features, I find this shift both necessary and a bit overdue.
The Standalone MCP Adapter Strategy
One of the biggest technical pivots discussed was the decision to ship the MCP (Model Context Protocol) adapter as a standalone plugin on WordPress.org. This is a smart move. By decoupling the adapter from the main AI plugin, the team is effectively isolating the “translation layer” that allows AI agents to talk to WordPress. For those out of the loop, the MCP adapter bridges the Abilities API to the Model Context Protocol specification.
Consequently, this means your custom “abilities” can soon be discovered by any MCP-compliant client (like Claude Desktop or Cursor) without you having to write a custom bridge every time. However, this also introduces a new maintenance surface. The team is currently untangling who “owns” the WordPress Agent Skills work versus the core adapter logic.
Security Hurdles in WordPress Core AI
I’ve seen plenty of “race conditions” and “transient” bugs, but security is where AI integrations usually fall flat. A major highlight this week was the “Connector Approval Experiment.” Specifically, the goal is to prevent a random plugin from hijacking a user’s OpenAI or Anthropic connection without explicit permission.
If you’re building custom integrations, you should read my previous take on why connector approval is the next big dev hurdle. It’s not just about UI; it’s about establishing a trust layer that doesn’t exist in the current WordPress hook system.
Refactoring the Abilities API
The team is currently refining “slug fragments” for the Abilities API. This sounds like minor polish, but it’s critical for roadmap visibility. Without consistent slug management, identifying and prioritizing specific AI capabilities across different themes and plugins becomes a nightmare. For a deeper dive into how this affects your 7.0 readiness, check out 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” Is Now Priority One
The release of WordPress Core AI version 0.9.0 is scheduled for next week, with 1.0.0 potentially dropping just before the WordPress 7.0 release on May 20. The most encouraging news? The team agreed that “polishing existing functionality is currently more important than introducing new experiments.” They are aggressively testing compatibility with heavyweights like Elementor, ACF, and Yoast.
Look, if this WordPress Core AI stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
The Pragmatic Takeaway
Don’t wait for May 20 to start testing. The split of the MCP adapter into a standalone plugin means you can start building “Agent Skills” now without bloating your core site logic. Therefore, your focus should be on security—specifically how your site handles connector approvals—and ensuring your custom hooks don’t conflict with the new Abilities API standards. We’re moving toward a version of WordPress that isn’t just a CMS, but an AI-native operating system. Refactor now, or debug later.
