WordPress 7.0 ships today, May 20, 2026. The headline feature in every press release is the AI Client, a provider-agnostic PHP API that lets plugins talk to Anthropic, Google, and OpenAI through a single interface. It is genuinely useful, and it is the thing every demo this week will show. But it is not the most important AI infrastructure WordPress has shipped in the last six months. The Abilities API, which landed quietly in WordPress 6.9 back in November 2025, and the MCP Adapter, which is still a separate plugin, are the architectural bets. If you are a plugin developer, those two are where I would put my first weeks of learning, not the AI Client.
TL;DR
- The AI Client (new in 7.0) makes WordPress a caller of AI providers. Three lines of code, immediate visible output, no ecosystem coordination required.
- The Abilities API (in core since 6.9) and the MCP Adapter (separate plugin, currently v0.5.0) make WordPress a callee that external AI agents like Claude, Cursor, and ChatGPT can discover and invoke.
- The callee interface outlives any individual provider relationship. The AI Client is a thin abstraction that competes with what a good HTTP library already does.
- Core ships zero cost controls and zero rate limits for AI Client usage. Provider-side spend caps are still your only safeguard. API keys are stored unencrypted in the database (ticket #64789).
Table of contents
- What is new in May 20, and what already shipped
- The AI Client is the part everyone will demo first
- The Abilities API is the primitive that matters
- Building an ability worth exposing
- Adding MCP turns the ability into a tool agents can call
- The cost control gap nobody has filled yet
- The security gaps you should design around
- What plugin developers should learn first
- Key takeaways
What is new in May 20, and what already shipped
A surprising amount of the WordPress AI story has been hiding in plain sight for half a year. The Abilities API has been in core since WordPress 6.9 in November 2025. It is the function that lets a plugin or theme register a discrete unit of functionality (think: "summarize a post", "schedule a refund", "tag an image") with a permission check, an input schema, and an output schema. None of that is AI-specific. It is a clean, reusable description of what your code can do.
Today, WordPress 7.0 adds three things on top of that foundation. First, the PHP AI Client (wordpress/php-ai-client, currently v1.3.1) is now bundled in core, with a WordPress wrapper exposed through wp_ai_client_prompt(). Second, the Connectors API gives site administrators a Settings > Connectors page to configure provider credentials. Third, two JavaScript packages (@wordpress/abilities and @wordpress/core-abilities) bring abilities to the block editor.
The MCP Adapter is not in core. It is a separate plugin, currently at v0.5.0, that the AI team has decided to keep on its own release cadence. The older Automattic/wordpress-mcp repository was archived on January 19, 2026, and WordPress/mcp-adapter is the canonical implementation going forward.
For context on what the May 20 release means at the user-facing level, my WordPress 7.0 overview is the version aimed at site owners. This article is the plugin developer's version.
The AI Client is the part everyone will demo first
The AI Client is irresistible to demo because it produces visible output in three lines:
$result = wp_ai_client_prompt(
'Summarize this article in 2-3 sentences: ' . $post_content
)
->using_max_tokens( 200 )
->using_temperature( 0.5 )
->generate_text();
if ( is_wp_error( $result ) ) {
return $result;
}The full builder surface is documented in the introduction post. It includes using_model_preference(), with_system_instruction(), as_json_response(), generate_image(), is_supported_for_text_generation(), and a GenerativeAiResult return type that exposes token usage data. (Caveat: I am citing these from the documented API surface during the RC cycle. If you are reading this after a 7.0.1 patch, check the current handbook for any signature changes.)
Credentials never appear in this code. The site administrator configures keys in Settings > Connectors, and the AI Client resolves them at call time. That is good design. As a plugin developer, you describe what you need (a text generation, a temperature, a max token count), and core handles the routing.
But there are three things this code does not give you. It does not give you a way for an external AI agent to call your plugin. It does not give you a budget. And it does not give you a way for another plugin to discover that your "summarize a post" feature exists. For all three of those, you need the Abilities API.
The Abilities API is the primitive that matters
The Abilities API does one thing well. It lets you register a typed, permission-gated, schema-validated function with WordPress, and it lets anyone (your own UI, the REST API, an MCP client, the block editor) discover and execute it.
That sounds modest. It is not. The reason it matters is that "anyone" includes things WordPress does not yet know about. An AI agent that does not exist today, written by a vendor that does not exist today, can connect to a WordPress site that registered abilities five years ago and figure out what that site can do. That is what the Abilities API gives you, and that is what the AI Client does not.
A useful way to think about it: the AI Client makes WordPress a caller. Abilities + MCP make WordPress a callee. The callee interface is the one that survives provider churn. Anthropic, Google, and OpenAI will rise and fall and rebrand and acquire each other. The convention "WordPress sites describe what they can do via abilities, and agents call those abilities via MCP" is the kind of thing that outlasts any one vendor.
Important nuance: this is an architectural argument, not a market observation. Today, in May 2026, the AI Client is what makes AI features possible inside WordPress. The Abilities + MCP combination needs the ecosystem to register meaningful abilities before its value compounds. If plugin developers do not do that work, the architecture has nothing to expose. So the spine of this article is not "ignore the AI Client." It is "if you only have time to learn one thing well, learn the Abilities API, because it is the part that locks in WordPress as an AI-native platform regardless of which provider wins."
Building an ability worth exposing
A real ability has four moving parts: a stable namespaced ID, an input schema, a permission callback, and an execute callback. Here is what a credible "summarize a post" ability looks like:
add_action( 'wp_abilities_api_init', function () {
wp_register_ability(
'acme-summarizer/summarize-post',
array(
'label' => __( 'Summarize a post', 'acme-summarizer' ),
'description' => __(
'Generates a 2-3 sentence summary of a published post.',
'acme-summarizer'
),
'category' => 'content',
'input_schema' => array(
'type' => 'object',
'properties' => array(
'post_id' => array(
'type' => 'integer',
'description' => 'The published post ID to summarize.',
),
),
'required' => array( 'post_id' ),
),
'output_schema' => array(
'type' => 'object',
'properties' => array(
'summary' => array( 'type' => 'string' ),
),
),
'execute_callback' => 'acme_summarize_post',
'permission_callback' => function ( $input ) {
return current_user_can( 'edit_post', $input['post_id'] );
},
'meta' => array(
'show_in_rest' => true,
'mcp' => array( 'public' => true ),
),
)
);
} );A few things deserve their own paragraph.
The namespace prefix (acme-summarizer/) is not optional in spirit. There is no global ability registry, but wp_get_abilities() returns everything registered on the site, and a flat namespace will produce collisions the moment two plugins both ship a summarize-post ability. Use your plugin slug.
The permission_callback runs before execution and receives the validated input. Treat it as the only line standing between an external agent and your data. current_user_can( 'edit_post', $input['post_id'] ) is correct because it ties the check to the specific post being summarized, not to a generic "user can edit something." The Abilities API does not yet distinguish between "this call came from a logged-in admin in the block editor" and "this call came from Claude Desktop over MCP." Your callback is the entire access control surface.
The input_schema doubles as documentation for the AI provider that will eventually call this ability. A sloppy schema confuses models. A clear, well-described schema turns into a clear, well-formed function call. Treat it like a public API contract, because for any agent that ever connects to this site, that is exactly what it is.
The meta.show_in_rest and meta.mcp.public flags are how this ability becomes accessible. The first exposes a POST /wp-json/wp-abilities/v1/abilities/acme-summarizer/summarize-post/run endpoint. The second is what the MCP Adapter looks for.
Adding MCP turns the ability into a tool agents can call
The MCP Adapter, currently v0.5.0, is a separate plugin you install alongside your code. The contract is simple: any registered ability with meta.mcp.public => true automatically becomes an MCP tool on the default server (mcp-adapter-default-server). External agents that connect via MCP can discover it, see the input schema, and invoke it.
There are two transports. STDIO is for local development through WP-CLI, and pairs naturally with the workflow I covered in WordPress Playground + MCP. HTTP is for production sites and uses the MCP 2025-06-18 specification, with application passwords as the primary authentication mechanism. There is no first-party OAuth solution for self-hosted sites yet.
If you need more control than the default server gives you (for example, scoping a subset of abilities to a specific MCP client, or running a custom server with stricter validation), the adapter exposes a mcp_adapter_init hook and a $adapter->create_server() method. For most plugin developers, the default server with selective meta.mcp.public flags is enough.
There is one footgun worth flagging. Anthropic's function calling expects tool names that match ^[a-zA-Z0-9_-]{1,64}$, but ability names use slashes (acme-summarizer/summarize-post). Practitioners (J.CV's writeup on building agentic loops is the clearest I have read) have settled on mapping / to __ when handing abilities to Anthropic models. If your plugin builds its own agent loop on top of the AI Client and Abilities, you will hit this. The MCP Adapter handles the mapping for MCP clients, so this is mostly an issue for in-process function calling, not for external agents.
The cost control gap nobody has filled yet
This is the section I want plugin developers to internalize before May 21.
WordPress 7.0 ships zero cost controls in core. There is no monthly token budget, no per-plugin spend cap, no rate limit, no admin dashboard showing which plugins are using how much. The AI Client gives you using_max_tokens() to bound a single request. That is it.
The only gate-style control is the wp_ai_client_prevent_prompt filter, which can block a prompt entirely based on user role, plugin identity, or any other condition. It is binary. Block or allow. Not "block after this user has consumed 50,000 tokens this month."
add_filter( 'wp_ai_client_prevent_prompt', function ( $prevent ) {
if ( ! current_user_can( 'edit_others_posts' ) ) {
return new WP_Error(
'ai_disabled',
__( 'AI features are unavailable for this role.', 'acme-summarizer' )
);
}
return $prevent;
}, 10 );Beyond that, your only reliable safeguard is provider-side spend caps. Set a hard monthly limit at OpenAI, Anthropic, and Google before you ever paste a key into Settings > Connectors. The April 9 AI Contributor Weekly Summary confirmed that rate limits and fallback behavior are "larger themes requiring asynchronous discussion", which is the polite way of saying it is on the roadmap but not on the May 20 release. Ticket #64706 is tracking a configuration constant to disable AI entirely, but that is a kill switch, not a budget.
If your plugin will make AI Client calls at any meaningful scale, write your own per-user quota and per-month budget into the wp_ai_client_prevent_prompt filter. Today. Before it ships. The plugins that survive the first wave of unhappy AI bills will be the ones that built the brake pedal themselves.
The security gaps you should design around
Two are worth knowing about and designing for.
API keys are stored in the database unencrypted, masked only in the admin UI. Ticket #64789 is tracking the encryption work, and the Connectors API supports three credential sources in priority order: environment variable, PHP constant, then database. If your plugin ships to clients you trust to set environment variables, recommend that path in your readme. For higher-stakes deployments, a database dump from a compromised backup is a credential leak.
Sandboxing for MCP-invoked abilities does not exist. Your permission_callback is the entire access control surface, and it cannot tell whether it is being called from a logged-in editor in the block editor, an authenticated REST request, or an MCP client connected via application password. If your ability does anything destructive, write the permission check as if any caller might be hostile. current_user_can( 'edit_post', $post_id ) is good. return true; is a future incident report.
The MCP Adapter README is also clear that the Jetpack Autoloader is "highly recommended" to prevent version conflicts when multiple plugins depend on the adapter. If your plugin will ship with the MCP Adapter as a dependency, follow that recommendation.
What plugin developers should learn first
If you have one weekend, read the Abilities API handbook and write three abilities for an existing plugin. Pick the three operations that an AI assistant would most plausibly want to call ("create a draft from an outline", "tag an image", "schedule a post"). Get the input schemas right. Get the permission callbacks right.
If you have a second weekend, install the MCP Adapter, mark those three abilities meta.mcp.public => true, and connect Claude Desktop or Cursor to your local site. See what happens when an external agent reads your schemas.
If you have a third weekend, write the AI Client integration. By that point, you will already understand where to put the cost controls, where to put the permission checks, and why the AI Client is the easy part.
The plugins that win the next two years of WordPress AI are not going to be the ones with the most impressive wp_ai_client_prompt() demos. They are going to be the ones with the cleanest abilities, the strictest permission callbacks, and the most thoughtful MCP exposure. That work compounds. The AI Client demo does not.
Key takeaways
- The Abilities API has been in core since WordPress 6.9 (November 2025). The MCP Adapter is a separate plugin, currently v0.5.0, deliberately kept out of core. The AI Client is what is new in 7.0 today.
- Abilities + MCP make WordPress callable by external AI agents. That callee interface outlives any individual provider. The AI Client is a thin abstraction that mostly competes with a good HTTP library.
- A real ability has a namespaced ID, an input schema, a
permission_callbackthat gates the actual operation, andmeta.mcp.public => trueif you want agents to find it. - WordPress 7.0 ships no cost controls. The
wp_ai_client_prevent_promptfilter is binary. Provider-side spend caps and a self-built per-user quota are your only real safeguards. - API keys in the Connectors API are unencrypted in the database. Recommend environment variables or PHP constants for any deployment that takes credential security seriously.