WordPress 7.0's AI Layer: An Engineering Assessment of What Actually Ships on April 9

If you've been building on WordPress long enough, you've watched a familiar cycle play out with every major technology wave. First, the plugin ecosystem fragments — a dozen competing plugins all wrapping the same third-party API, each with its own settings page, its own credential storage, its own opinions about how things should work. Then, eventually, WordPress core absorbs the pattern into something standard. It happened with REST APIs. It happened with the block editor. And on April 9, it's happening with AI.

WordPress 7.0 ships a provider-agnostic AI layer built directly into core: an AI Client PHP API, capability discovery via the Abilities API, a Connectors registry for credential management, and an MCP Adapter that exposes WordPress to AI agent toolchains. Not a plugin. Infrastructure.

We've spent the last few weeks digging through the RC builds, reading the core proposals, and testing the APIs. Here's what we found — what's well-designed, what's genuinely forward-thinking, and where the gaps are that nobody's talking about yet.

The Architecture at a Glance

WordPress 7.0's AI layer is four components working together:

The separation of concerns is clean. The AI Client handles model interaction. Connectors handles authentication and credential management. Abilities handles capability discovery. MCP handles external tool access. No component depends on another to function, but they compose well together.

This is infrastructure, not an application. WordPress 7.0 doesn't ship AI features that end users interact with. It ships the layer that plugin developers build on. The distinction matters — and the WordPress core team has been explicit about it.

AI Client: The wp_mail() of AI

The AI Client wraps the standalone wordpress/php-ai-client package (v1.3.1) and exposes it through WP_AI_Client_Prompt_Builder. The analogy to wp_mail() is apt: just as WordPress standardized email so every plugin doesn't need its own SMTP configuration, the AI Client standardizes model interaction so every plugin doesn't need its own provider SDK.

The fluent API is well-designed:

$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();

What's worth noting about the design:

Provider abstraction is real, not superficial. The AI Client doesn't just wrap API calls — it normalizes response formats. generate_text() returns the same structure regardless of whether Anthropic, Google, or OpenAI is processing the request. The _result() variants (generate_text_result(), generate_image_result()) return a GenerativeAiResult object with getTokenUsage(), getProviderMetadata(), and getModelMetadata() — meaning you can instrument cost tracking and provider comparison at the application level without provider-specific code.

Support detection works without API calls. Methods like is_supported_for_text_generation() and is_supported_for_image_generation() check capabilities locally before burning tokens. This is the right call for cost-conscious deployments.

The filter hook wp_ai_client_prevent_prompt is important. It lets you intercept and block specific prompts before they reach a provider. For organizations with compliance requirements — content restrictions, data classification, PII screening — this is where you'd implement guardrails. All errors return WP_Error, keeping the pattern consistent with WordPress conventions.

Three official provider plugins ship at launch: Anthropic (Claude), Google (Gemini), and OpenAI (GPT). The connector architecture is open — any provider can build one, and the API key resolution order is sensible: environment variable > PHP constant > database setting. If you're managing credentials through environment variables or wp-config.php constants (as you should be in production), the database is never touched.

Connectors API: Centralized Credential Management

The Connectors API (WP_Connector_Registry) is a general-purpose registry for external service connections. AI providers are the first use case, but the architecture is explicitly designed for non-AI services too — payment processors, email platforms, analytics, CRMs.

The admin UI at Settings > Connectors renders each registered connector as a card showing name, description, logo, install/activate status, and connection health. Registration happens via the wp_connectors_init 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 are validated against /^[a-z0-9_-]+$/ — no namespace collisions from creative naming.

The architectural decision to make this a general connector registry rather than an AI-specific settings page is forward-thinking. It signals that WordPress sees AI as one category of external service, not a special case. For teams managing multiple WordPress properties, having a single, consistent interface for all external connections reduces configuration drift across environments.

One concern: API keys stored in the database are unencrypted (masked in the UI, but plaintext in wp_options). The env var / constant resolution order mitigates this for teams that follow deployment best practices, but shared hosting environments where database access is less controlled should be aware. This isn't a WordPress 7.0 regression — it's the same pattern wp_mail() uses for SMTP credentials — but it's worth noting as AI API keys tend to carry higher financial exposure than most WordPress credentials.

Abilities API: Capability Discovery Done Right

The Abilities API is the most architecturally interesting component. It's a client-side (JavaScript) system built on two packages: @wordpress/abilities for registration and execution, and @wordpress/core-abilities for bridging to server-registered capabilities via REST.

The core API:

registerAbility({
    name: 'generate-alt-text',
    category: 'media',
    execute: async (params) => { /* ... */ },
    input_schema: { /* JSON Schema draft-04 */ },
    output_schema: { /* JSON Schema draft-04 */ },
    permissionCallback: () => currentUserCan('upload_files'),
    meta: {
        readonly: false,
        destructive: false,
        idempotent: true,
    }
});

The metadata annotations — readonly, destructive, idempotent — are a governance feature disguised as a developer convenience. They let orchestration layers (including the MCP Adapter) make informed decisions about what an ability can do without executing it. An AI agent interacting with your site via MCP can see that delete-post is destructive and get-post is readonly, and adjust its behavior or require confirmation accordingly.

Input and output validation uses JSON Schema (draft-04), which is battle-tested and well-tooled. Permission control via permissionCallback ties into WordPress's existing capabilities system — no new auth model to learn.

This integrates with @wordpress/data stores and useSelect(), so React-based UI components can reactively respond to available capabilities. When a connected model changes, the UI can update what's available without a page reload.

MCP Adapter: WordPress Enters the Agent Ecosystem

The MCP Adapter is the component with the widest implications beyond WordPress itself.

MCP — Model Context Protocol — has hit 97 million monthly npm downloads. Semrush, Ahrefs, Frase, GitHub, and Google's ADK have all shipped MCP integrations. When WordPress adopts MCP, it's not joining an experiment — it's joining infrastructure.

The adapter (WP\MCP\Core\McpAdapter) bridges the Abilities API to MCP. It auto-registers a default MCP server exposing three system tools:

• mcp-adapter-discover-abilities — list available abilities
• mcp-adapter-get-ability-info — get schema and metadata for a specific ability
• mcp-adapter-execute-ability — execute an ability with validated parameters

Plugins expose abilities as MCP tools by adding 'meta' => ['mcp' => ['public' => true]] during ability registration. Custom MCP servers can be created via $adapter->create_server() on the mcp_adapter_init hook.

Two transport modes:

• STDIO (local): wp mcp-adapter serve via WP-CLI. For development, local AI assistants (Claude Code, Cursor, VS Code).
• HTTP (remote): Via @automattic/mcp-wordpress-remote with WordPress app passwords. For production agent access.

The practical implication: any AI coding assistant or agent framework that speaks MCP can now interact with any WordPress 7.0 site through a standardized interface. For teams running 10, 50, or 500 WordPress properties, this means content management, monitoring, and operational workflows can be built once and applied consistently across every site — without per-site custom integrations.

What's Missing

The AI layer is well-designed infrastructure. But infrastructure is not a solution, and it's worth being honest about what WordPress 7.0 does not ship:

No AI-powered search. The AI Client can connect to language models, but it doesn't index content, build embeddings, or provide semantic search. WordPress's default search is still a MySQL LIKE query — the same pattern since the early 2000s. The AI Client gives you a way to send prompts to a model. It does not give you a way to make your site's content intelligently searchable.

No content intelligence. There's no built-in content analysis, categorization, recommendation engine, or personalization. The AI Image Editing feature (background removal, expansion, element replacement) ships as an experimental plugin (AI 0.6.0), not as core — and it's focused on media editing, not content understanding.

No agent governance framework. The MCP Adapter exposes abilities to external agents, but there's no built-in audit logging, rate limiting, or approval workflow for agent actions. The destructive and idempotent metadata annotations are hints, not enforcement. If you're exposing your site to AI agents in production, you'll need to build your own governance layer — or wait for the plugin ecosystem to provide one.

No cost management. Token usage tracking via getTokenUsage() gives you the data, but there's no built-in budget management, per-user cost allocation, or spend alerting. For organizations concerned about runaway API costs, this is a gap you'll need to fill at the application layer.

What to Do Now

If you maintain WordPress infrastructure at any scale, here's the practical assessment:

Test on staging now. RC2 is available. The AI Client API is stable and the string freeze is locked. If you have plugins that wrap their own AI SDKs, evaluate whether migrating to the AI Client reduces your dependency surface.

Evaluate credential management. If you're managing AI API keys across multiple WordPress properties, the Connectors API and its env var resolution order may simplify your deployment pipeline. If you're on shared hosting, assess the unencrypted database storage against your risk tolerance.

Map your Abilities API surface. If you build plugins, the Abilities API is the new standard for exposing functionality — to the block editor, to other plugins, and via MCP to external agents. Starting with the Abilities API now means your plugin is MCP-compatible by default.

Don't rush to production. The standard guidance applies: wait 1-2 weeks post-release for hotfix patches before updating production sites. The AI layer is entirely opt-in — nothing activates until you configure a provider, and a single configuration constant disables all LLM features.

WordPress powers 43% of the web. A provider-agnostic AI layer in core doesn't just affect WordPress — it reshapes what AI tool builders can assume about the CMS landscape. The infrastructure is solid. What gets built on it is the story that matters next.

This is the first in a five-part series on WordPress 7.0's AI architecture. Next: a deeper dive into the AI Client and MCP Adapter, with implementation patterns for plugin developers.

FAQ

What AI providers does WordPress 7.0 support?
At launch, official connector plugins ship for Anthropic (Claude), Google (Gemini), and OpenAI (GPT). The Connectors API is open — any provider can build a connector. Self-hosted models (via OpenRouter or direct inference endpoints) work through custom connectors.

Does the AI Client replace existing AI plugins?
Not immediately. Existing plugins that bundle their own provider SDKs will continue to work. Over time, plugins that migrate to the AI Client will benefit from shared credential management, provider switching, and the Abilities/MCP ecosystem. It's an adoption curve, not a hard cutover.

How does MCP in WordPress compare to MCP in other platforms?
WordPress's implementation is Abilities-first — plugins register abilities, and the MCP Adapter exposes them as MCP tools. This is architecturally similar to how GitHub and Semrush expose their APIs via MCP, but with the additional layer of WordPress's permission system and the readonly/destructive/idempotent metadata annotations.

What are the security implications of the MCP Adapter?
The MCP Adapter inherits WordPress's authentication model. STDIO connections (local, via WP-CLI) run with the permissions of the WP-CLI user. HTTP connections require WordPress app passwords and inherit the permissions of the authenticated user. No anonymous MCP access is possible. However, there is no built-in audit log for MCP-initiated actions — consider logging plugins if you're exposing MCP in production.

Should I update to WordPress 7.0 on April 9?
For staging and development environments, yes — test immediately. For production, wait 1-2 weeks for any hotfix releases. The AI features are entirely opt-in with zero performance impact if unconfigured.

Can I disable all AI features?
Yes. A single configuration option disables all LLM-related features. If you don't want AI on your site, it's a one-line change.