Inside WordPress 7.0's AI Architecture: What the AI Client, Abilities API, and MCP Adapter Actually Do

WordPress 7.0 is still in its extended RC cycle — the AI features are ready, but Real-Time Collaboration is getting an architectural rework before the team signs off on GA. Late May is the current realistic window. Which means you have more time than you expected to understand what you're actually building on.

We covered the broad engineering picture in Article 1. The architecture table, the high-level design intent, what's well-designed and what's missing. If you haven't read it, start there.

This is the developer's guide. What does the code actually look like? How do these four components compose? What does this change about how you build a WordPress plugin in 2026? And — the question we've been asked a dozen times in the RC period — what does the AI layer not give you?

There are four components. They're independent but designed to work together. None depends on another to function, but the combination is worth more than the sum of its parts.

The Architecture in One Table

The intended reading: the Connectors API stores credentials. The AI Client uses those credentials to call providers. The Abilities API describes what the site can do. The MCP Adapter exposes those abilities to agents outside WordPress.

AI Client: The wp_mail() of AI

If you've been building WordPress plugins long enough to remember writing your own SMTP integration, you already understand what the AI Client does. Before wp_mail(), every plugin that needed to send email bundled its own SMTP library and its own settings page. wp_mail() standardized the interface. The AI Client does the same for model interaction.

The entry point is a fluent builder:

$result = wp_ai_client_prompt('Summarize this article for a newsletter')
    ->with_text($article_content)
    ->using_temperature(0.3)
    ->using_max_tokens(500)
    ->generate_text();

generate_text() returns a consistent structure regardless of which provider is configured — Anthropic, Google, OpenAI, or any community connector. Your plugin writes against one interface; the operator decides which model is on the other end.

The result variants are where it gets useful. generate_text_result() (and generate_image_result()) return a GenerativeAiResult object:

$result = wp_ai_client_prompt('Generate product alt text')
    ->with_image($attachment_url)
    ->generate_image_result();
$tokens = $result->getTokenUsage();         // input + output token counts
$provider = $result->getProviderMetadata(); // which provider, which endpoint
$model = $result->getModelMetadata();       // model ID, version

This matters for cost tracking. If you're building a plugin that calls the AI Client, you can instrument getTokenUsage() to give site operators visibility into what your plugin is spending — without any provider-specific code. That's meaningful in a world where core ships no cost caps and the site operator can't easily see which plugin is burning tokens.

Support detection before the API call. Check capabilities locally before you incur token costs:

if ( ! wp_ai_client()->is_supported_for_image_generation() ) {
    // Fall back gracefully — don't fail silently
    return;
}

This is the right pattern for multi-provider environments. A site running Anthropic Claude doesn't have the same image generation capabilities as one running OpenAI's DALL-E connector. Write for heterogeneity.

The wp_ai_client_prevent_prompt filter hook. This is underappreciated:

add_filter( 'wp_ai_client_prevent_prompt', function( $prevent, $prompt_builder ) {
    // Intercept and inspect the prompt before it leaves the site
    if ( contains_pii( $prompt_builder->get_prompt_text() ) ) {
        return true; // Block this prompt
    }
    return $prevent;
}, 10, 2 );

For compliance-sensitive deployments — healthcare, legal, government — this is where PII screening, content classification, and prompt filtering live. Any governance plugin that wants to add prompt-level controls has a clean hook point. All errors return WP_Error, consistent with WordPress conventions.

What this means if you build plugins today. If your plugin currently bundles its own Anthropic, OpenAI, or Google SDK, the migration case is straightforward: you drop a dependency, your plugin works with any provider the site operator has configured, and your users stop maintaining a separate API key in your settings page. The adoption curve will be gradual — existing plugins won't rewrite overnight — but for new plugins and major-version rewrites, the AI Client is the correct default.

Connectors API: Credential Management as Infrastructure

The Connectors API lives at Settings → Connectors. It's a general-purpose registry for external service connections — not AI-specific, even though AI providers are the first use case. The naming deliberately avoided "AI Connectors" to make room for future non-AI integrations: payment processors, email platforms, CRMs.

Three official provider plugins ship at launch: Anthropic, Google, and OpenAI. Community connectors in late-RC testing include Grok, Mistral, Ollama (local inference), and OpenRouter (which aggregates 400+ models). That last one is worth noting: OpenRouter as a community connector means sites can access models that don't have official WordPress connector plugins without each plugin maintaining its own routing logic.

Registration is one action hook:

add_action( 'wp_connectors_init', function( $registry ) {
    $registry->register( 'my-service', [
        'name'        => 'My Service',
        'description' => 'Integration with My Service API',
        'plugin'      => [ 'slug' => 'my-service-connector' ],
    ] );
} );

Connector IDs validate against /^[a-z0-9_-]+$/. No namespace collisions from creative naming.

Credential resolution order matters in production:

Environment variable → PHP constant → Database

If you set CONNECTOR_MY_SERVICE_API_KEY as an environment variable, that takes priority over anything stored in the database. For teams managing deployments across multiple WordPress properties — and this is a real use case for agencies managing 50 or 100 sites — moving credentials to env vars means secrets live in your deployment pipeline, not in each site's wp_options table. A single Terraform config or .env template instead of 50 individual settings screens.

The known limitation. Database-stored keys are plaintext (masked in the admin UI, but not encrypted at rest). This is the same pattern as wp_mail() and SMTP credentials, but AI API keys carry higher financial exposure. The mitigation is the env var / constant resolution order: teams that follow deployment best practices never touch the database. Shared-hosting environments are the real exposure surface here.

Access to the Settings → Connectors screen is gated by the new prompt_ai capability, restricted to administrators by default. Fine-grained per-role control is a plugin opportunity — core leaves that gap intentionally.

Abilities API: The Piece That Makes Everything Else Meaningful

The Abilities API is, architecturally, the most interesting part of WordPress 7.0's AI layer. It's also the easiest to underestimate.

On the surface it looks like a JavaScript capability registry. You register an ability, it shows up in the Abilities Explorer, and other components can invoke it. Useful, but modest.

The thing it actually is: a machine-readable, permission-aware description of what your site can do. That distinction matters.

Registration:

import { registerAbility } from '@wordpress/abilities';
registerAbility({
name: 'generate-post-summary',
category: 'content',
execute: async ({ postId, length }) => {
return apiFetch({
path: /my-plugin/v1/summarize/${postId},
data: { length },
method: 'POST',
});
},
input_schema: {
type: 'object',
properties: {
postId: { type: 'integer' },
length: { type: 'string', enum: ['short', 'medium', 'long'] },
},
required: ['postId'],
},
output_schema: {
type: 'object',
properties: {
summary: { type: 'string' },
word_count: { type: 'integer' },
},
},
permissionCallback: () => wp.data.select('core').canUser('update', 'posts'),
meta: {
readonly: false,
destructive: false,
idempotent: false,
},
});

Input and output validation uses JSON Schema draft-04. Permission control ties into WordPress's existing capabilities system. No new auth model to learn.

The meta annotations are a governance feature. This is the part that sounds like developer documentation but has operational implications.

readonly, destructive, and idempotent are machine-readable hints. They let orchestration layers — including the MCP Adapter and any agent framework that reads them — make decisions about what an ability can do before executing it.

An AI agent interacting with your site via MCP can read that delete-post is destructive before calling it. An orchestration layer can require human confirmation before invoking any ability where destructive: true. A security plugin can log every call to a non-idempotent ability. None of this requires the orchestration layer to understand what your ability does — it just reads the flags.

The longer-term implication: as AI agents become more capable and more autonomous, the governance signal your plugin sends through these metadata fields will matter more. Plugins that thoughtfully annotate their abilities will compose better with agent frameworks. Plugins that set everything to readonly: true to avoid scrutiny will become a liability.

Three core abilities ship in WordPress 6.9 and are available today: - core/get-site-info - core/get-user-info - core/get-environment-info

These serve as reference implementations for the registration pattern. If you're uncertain about how to structure an ability for your plugin, reading the core implementations is a useful starting point.

Reactive integration with @wordpress/data. The Abilities API integrates with data stores and useSelect(), so React-based UI components can respond to what's available:

const { generateSummary } = useSelect( ( select ) => ({
    generateSummary: select( 'core/abilities' ).getAbility( 'generate-post-summary' ),
}) );

When an administrator changes the connected provider, the UI updates what's available without a page reload. Build capability-aware UI, not hardcoded assumptions.

MCP Adapter: Your Plugin Is Now a Tool

The MCP Adapter is the component with the widest implications beyond WordPress itself — not because of what it does inside WordPress, but because of what it makes WordPress into from the outside.

MCP — the Model Context Protocol — has hit 97 million monthly npm downloads and has been adopted by GitHub, Semrush, Ahrefs, Cloudflare, and Google's agent development kit. When an AI assistant needs to interact with an external system, MCP is increasingly the protocol it expects. WordPress shipping an MCP Adapter means any AI agent that speaks MCP can now interact with any WordPress 7.0 site through a standardized interface.

The adapter auto-registers three meta-abilities on any MCP-connected site: - mcp-adapter/discover-abilities — list available abilities on this site - mcp-adapter/get-ability-info — get schema and metadata for a specific ability - mcp-adapter/execute-ability — invoke an ability with validated parameters

Exposure is explicit, not automatic. An ability only becomes MCP-accessible when you flag it:

// Server-side registration with MCP exposure
add_action( 'wp_register_abilities', function() {
    wp_register_ability( 'my-plugin/update-product-price', [
        'execute_callback'     => 'my_plugin_update_price',
        'permission_callback'  => function() {
            return current_user_can( 'edit_products' );
        },
        'input_schema'  => [ /* JSON Schema */ ],
        'output_schema' => [ /* JSON Schema */ ],
        'meta' => [
            'readonly'    => false,
            'destructive' => false,
            'idempotent'  => true,
            'mcp'         => [ 'public' => true ],
        ],
    ] );
} );

The meta.mcp.public flag is the gate. This is the right design — you should be deliberate about what you expose to external agents, not opt-out of exposure after the fact.

Two transport modes serve different deployment contexts:

STDIO (local development):

wp mcp-adapter serve

Local WP-CLI connection. Right for development environments, local AI assistants (Claude Desktop, Claude Code, Cursor), and running agent workflows on a local site.

HTTP (production): Via @automattic/mcp-wordpress-remote with WordPress app passwords. Authentication inherits WordPress's app password model. Right for production sites where external agents need remote access.

For plugin developers, this is a new distribution surface. A plugin that registers well-designed abilities and exposes them via MCP doesn't just run when a human clicks a button. It runs when an agent discovers a tool. A developer managing 50 WordPress sites with Claude or another MCP-compatible AI assistant can invoke your plugin's abilities across every site without a custom integration — if you've registered those abilities correctly.

Think about what this means concretely: content audit automation, bulk metadata updates, inventory reconciliation, cross-site consistency checks. Workflows that currently require a developer to write custom REST calls for each site become describable in plain language once the MCP layer is in place.

Building abilities with clean schemas, accurate meta annotations, and sensible permission callbacks isn't just good hygiene. It's the difference between a plugin that works in the old WordPress world and one that works in the agent-accessible one.

The AI 0.6.0 / 0.7.0 Companion Plugin: What the Infrastructure Actually Looks Like in Use

WordPress core deliberately ships infrastructure, not end-user AI features. The companion AI plugin (renamed from "AI Experiments" in 0.6.0) is the team's own reference implementation — the first look at what building on top of the 7.0 layer looks like.

AI 0.6.0 (March 20): Image editing in the Media Library — background removal, background expansion, object removal and replacement. The first user-facing AI feature in the WordPress ecosystem that's built on the 7.0 architecture.

AI 0.7.0 (April 7): Content classification (suggested tags and categories), meta description generation, bulk alt-text generation across the media library, and an improved Abilities Explorer with category filtering.

The bulk alt-text generation is worth singling out. If you manage sites with image libraries that have no alt text — and most do — AI 0.7.0 gives you a practical starting point for accessibility remediation. Human review is still necessary; AI-generated alt text is often generic or lacks context. But it's a faster starting point than writing from scratch.

Study these plugins as reference implementations. They show how the WordPress AI team intended the architecture to be used — how abilities register, how the AI Client gets called, how results surface in the admin.

What the AI Layer Does Not Give You

The architecture is genuinely well-designed. It's also not a solution.

No AI search. The AI Client connects to language models. It does not index your content, build embeddings, understand semantic relationships, or fix the MySQL LIKE query that WordPress's default search has been running since the early 2000s. WordPress 7.0's AI layer and WordPress search are two separate systems that don't talk to each other.

No agent governance. The MCP Adapter exposes abilities to external agents with readonly/destructive/idempotent metadata annotations. These are hints, not enforcement. There is no built-in audit log for MCP-initiated actions, no rate limiting, no approval workflow for destructive operations. If you're exposing your site to AI agents in production, you'll need a governance layer — either one you build or one that emerges from the plugin ecosystem.

No cost management. getTokenUsage() gives you the data to build cost tracking. Core does not ship budget caps, per-user spend limits, or alerting. In a centralized credential model, one misbehaving plugin can burn tokens for every connected feature without the site operator noticing.

No brand voice or content constraints at the system level. Gutenberg 22.7 ships a Guidelines feature — storage for site-wide and block-level content guidelines with import/export and revision history. It does not ship enforcement. Every plugin that generates content decides whether it honors the guidelines. The gap between "guidelines exist" and "guidelines are applied" is a product layer problem, not a platform layer one.

(Full disclosure: we build wpRag — an AI search plugin for WordPress — so we've been living inside these APIs since the early RCs. The AI Client is solid infrastructure. But it connects to language models; it doesn't make your content searchable. That's the layer we build on top. If you're curious what a plugin built on WordPress 7.0's AI architecture actually looks like in practice, that's us.)

What to Do Now

WordPress 7.0 is expected to ship in late May. The AI layer is stable; the extended RC cycle is about Real-Time Collaboration's data architecture, not AI. The playground at playground.wordpress.net has RC builds you can test against today.

If you build plugins: - Register your capabilities as abilities. Even if you don't need MCP exposure today, registering abilities correctly means you're in the right pattern when you do. - Evaluate migrating from bundled provider SDKs to the AI Client. The migration effort is proportional to how tightly you've coupled to a specific provider's response format. - Annotate your ability metadata accurately. readonly, destructive, idempotent — these matter for anything that will orchestrate your abilities. - Test on playground.wordpress.net before GA to surface compatibility issues with the Abilities API or the new admin structure.

If you manage WordPress infrastructure: - PHP minimum for 7.0 is 7.4 — PHP 7.2 and 7.3 will not receive the 7.0 update. If you have sites on those versions, plan the PHP upgrade now. - Decide your credential management approach before you need it: env vars or constants are the right answer for any site you manage seriously. - The prompt_ai capability gates who can configure connectors. Decide before GA who holds that capability on your sites.

If you're building an AI feature that needs search: The Abilities API and AI Client are not that. They're the layer above which search features get built, not search itself.

This is the fourth article in our WordPress 7.0 series. Article 1 covers the engineering assessment of the full AI layer. Article 2 covers the delay and what it means for your timeline. Article 3 covers the agency preparation checklist. Next: WordPress 7.0 adds AI to your site — but your search is still broken, and in 2026 that matters more than it used to.

FAQ

What's the difference between the AI Client and the Connectors API? The AI Client is the prompt interface — the PHP API you call to interact with a language model. The Connectors API is the credential registry — where you store and manage the API keys the AI Client uses to authenticate with providers. They're designed to work together but serve different roles. You can have a connected provider with no AI Client calls, or (theoretically) use the AI Client against a custom provider you've registered separately.

Can I use the AI Client with a self-hosted model? Yes, via OpenRouter or a custom connector. OpenRouter aggregates 400+ models including locally-hosted ones. If you're running inference on your own infrastructure, you can build a custom connector that registers with wp_connectors_init and routes calls to your endpoint.

Is the MCP Adapter secure? MCP connections inherit WordPress's authentication model. STDIO connections (local, WP-CLI) run with the WP-CLI user's permissions. HTTP connections require WordPress app passwords and inherit that user's permissions. No anonymous MCP access is possible. However, there is no built-in audit log for MCP-initiated actions. For production deployments, a logging plugin watching MCP calls is strongly recommended.

Do I have to rewrite my plugin to use the AI Client? No. Existing plugins that bundle their own provider SDKs will continue to work after 7.0 ships. The AI Client is the right default for new plugins and major-version rewrites. Migration is an adoption curve, not a forced cutover.

What PHP version does WordPress 7.0 require? PHP 7.4 minimum; PHP 8.3 recommended. WordPress 7.0 drops support for PHP 7.2 and 7.3 — sites on those versions will stay on the 6.9 branch and will not receive the automatic 7.0 update. If you have production sites on 7.2 or 7.3, planning the PHP upgrade before 7.0 GA is the move.

When does WordPress 7.0 ship? Late May 2026 is the current working window. The AI features are stable — the delay is exclusively about Real-Time Collaboration's data architecture. The core team has committed to publishing an updated final-stretch schedule. Watch make.wordpress.org/core.