If you came into this course believing “the MCP Adapter shipped in WordPress core,” you’re not alone, and you’re working from a claim that isn’t true. This lesson exists to correct that plainly, before you touch a single line of migration code, because building a migration plan on the wrong premise wastes real time. The good news: what actually did ship in core is still a meaningful upgrade, you just need the accurate version of it.
This lesson assumes you’ve built something against the Abilities API before, whether core’s version or the old standalone package. If abilities are a new concept to you, WordPress AI Foundations covers them from scratch first.
Step 1: The claim you may have heard, and why it’s wrong
A version of this course’s own brief once claimed “the MCP Adapter shipped in WordPress 7.0 core in April 2026.” That claim is false, and it’s worth naming directly since it circulates in enough secondhand summaries and outdated blog posts that you’ve likely run into some form of it.
Verified directly against the live github.com/WordPress/mcp-adapter repository and
make.wordpress.org: the MCP Adapter has not merged into WordPress core, and there is no
credible signal that it’s about to. It remains a separate plugin, on its own release
cadence, currently at v0.5.0. This was a deliberate decision by the WordPress AI team,
not a temporary gap waiting to close. Treat “MCP Adapter is a separate plugin you must
install yourself” as a stable, ongoing fact of this stack, not a caveat that will
expire.
Step 2: What did merge into core, and when
Two pieces of the AI stack are, in fact, in WordPress core now. Getting the dates right matters because they determine your minimum supported version for each feature.
| Piece | Status | Since |
|---|---|---|
| Abilities API | In WordPress core | 6.9 (“Gene”), released December 2, 2025 |
| PHP AI Client | In WordPress core (wp_ai_client_prompt()) | 7.0, announced March 24, 2026 |
| MCP Adapter | Separate plugin, not in core | Ongoing, currently v0.5.0 |
Notice the shape of that table: the two pieces that merged into core are both about WordPress’s own internal capability model, registering abilities, and calling out to an AI model from your own PHP code. The piece that stayed a plugin is the one that opens an inbound door, letting an external AI agent connect to your site at all. That’s not a coincidence, and it’s the actual reason behind the split.
Step 3: Why the MCP Adapter staying separate is deliberate
The Abilities API and the PHP AI Client are both “safe by default” in the sense that
neither one, on its own, creates a new network-facing surface. Registering an ability
doesn’t expose anything until something serves it externally. Calling
wp_ai_client_prompt() is outbound, your code choosing to ask a model something.
The MCP Adapter is different in kind: it’s the piece that listens for external AI clients and hands them a list of things your site will do on request. Keeping that on its own plugin release cadence lets the WordPress AI team ship security fixes, transport changes, and protocol updates to that specific, higher-risk surface without waiting on a full WordPress core release cycle, and lets site owners choose not to install it at all if they don’t want any external agent connectivity, while still benefiting from the Abilities API and PHP AI Client that shipped in core.
Step 4: What this means for your migration
If your codebase currently requires the archived wordpress/abilities-api Composer
package, that dependency is the one this course helps you remove, because its
functionality is now built into core. If any of your code, deployment scripts, or
internal documentation assumed the MCP Adapter didn’t need a separate install, that
assumption needs correcting too, and Lesson 7 deals with that specifically.
What you should not do is remove your MCP Adapter plugin dependency thinking core absorbed it. It didn’t. You still need it installed, activated, and kept up to date, exactly as before.
Test it: confirm your own site’s real status
Run this against any WordPress install you’re migrating, it tells you exactly which pieces are actually present, rather than which pieces you assume are present:
# Confirm WordPress core version
wp core version
# Confirm the Abilities API is in core (true on 6.9+)
wp eval 'var_dump( function_exists( "wp_register_ability" ) );'
# Confirm the PHP AI Client is in core (true on 7.0+)
wp eval 'var_dump( function_exists( "wp_ai_client_prompt" ) );'
# Confirm the MCP Adapter plugin is installed and active (never a core check)
wp plugin is-active mcp-adapter && echo "MCP Adapter plugin: active"If the fourth command reports the plugin inactive or not found, that’s expected on a fresh 6.9 or 7.0 install, it is not a bug, and it is not something updating WordPress core will fix. You install it deliberately, the same way you always did.
Seeing “MCP Adapter v0.5.0” and assuming that number implies a core release is a common misread. The MCP Adapter’s own version number is independent of WordPress core’s version number. It reaching 1.0 someday wouldn’t mean core absorption either, plenty of official WordPress plugins are stable, versioned, and permanently separate from core.
Recap
Two of the three pieces of the WordPress AI stack are genuinely in core now: the Abilities API since 6.9, and the PHP AI Client since 7.0. The third, the MCP Adapter, is not, and it isn’t a temporary gap, it’s a deliberate architectural choice to keep the inbound, agent-facing surface on its own independent release cadence. Your migration work in this course is about dropping the archived pre-core Abilities API package, not about removing an MCP Adapter dependency you still need.
Resources & further reading
- Abilities API in WordPress 6.9, make.wordpress.org
- Introducing the AI Client in WordPress 7.0, make.wordpress.org
- MCP Adapter repository, GitHub
- Archived abilities-api repository, GitHub
- WordPress 6.9 version page, wordpress.org
- Abilities API reference, developer.wordpress.org