WordPress 7.0 shipped on May 20, 2026 with AI built into core, but not in the way most headlines suggested. Core gives you plumbing: a provider-agnostic AI Client, a Settings > Connectors screen for provider credentials, and the Abilities API (first added in 6.9) that lets plugins describe actions an AI agent can call. The features you see, like alt text, excerpts and comment triage, come from plugins, and the model behind them comes from a provider you pay for.
This guide is for site owners and agencies deciding what to switch on: what each piece does, where your keys end up, what it costs, and how to connect an agent safely.
What AI in WordPress 7.x is, and what it isn't
There is no "AI Features" settings page. WordPress does not write posts, moderate comments or tune your cache on its own. Core added a shared layer, so plugins stop shipping their own API-key fields and vendor clients.
| Piece | What it does | Where it lives | Shipped in |
|---|---|---|---|
| Abilities API | Lets plugins register named actions with input/output schemas and permission checks | Core | 6.9 (server), 7.0 (client-side JS) |
| AI Client | One PHP interface (wp_ai_client_prompt()) for sending prompts to any configured provider | Core | 7.0 |
| Connectors API and screen | Stores provider credentials under Settings > Connectors | Core | 7.0 |
| Ability lifecycle filters | Hooks to log, gate, cache or rewrite ability execution | Core | 7.1 |
| AI Provider for Anthropic / Google / OpenAI | The code that talks to each vendor's API | Plugins on WordPress.org | Separate installs |
| AI plugin | Alt text, excerpts, titles, summaries, comment moderation, image generation and more | Plugin on WordPress.org (experimental) | Separate install |
| MCP Adapter | Exposes abilities to external agents over the Model Context Protocol | Plugin on WordPress.org | Separate install |
A fresh WordPress 7.1 install makes no AI calls at all. Nothing happens until someone adds a provider plugin, credentials and a plugin that uses the AI Client.
How the AI Client and Connectors work
The AI Client is a builder that plugin developers call. A feature asks for text or an image, optionally names a preferred model, and WordPress routes the request to a capable provider the site owner configured, falling back to any compatible model. With no provider configured, the call returns a WP_Error instead of breaking the page. It can also offer a model a specific list of abilities to call (using_abilities()), and only those.
Connecting a provider
- Install and activate a provider plugin, for example AI Provider for Anthropic.
- Open Settings > Connectors. Anthropic, Google and OpenAI appear as featured cards; other provider plugins register themselves automatically.
- Follow the card's link to the vendor's key page, create a key, and paste it in, or set it in the environment (below).
- Install a plugin that uses the AI Client, such as the official AI plugin, and enable only the features you want.
Provider choice affects what works. The featured Anthropic connector is described as text generation with Claude; the Google and OpenAI connectors cover text and image generation. If you want the AI plugin's image generation, you need a provider that does images.
Where the API keys live
Core resolves each key in this order: environment variable, then PHP constant, then the database setting. For AI providers the name follows the provider ID, so the Anthropic key is ANTHROPIC_API_KEY:
// wp-config.php, above "That's all, stop editing!"
// Skip this if your host sets ANTHROPIC_API_KEY as a server environment variable,
// which WordPress checks first.
define( 'ANTHROPIC_API_KEY', 'sk-ant-your-key-here' );
Keys saved through the Connectors screen are masked in the UI but not encrypted in the database. Whatever the source, the key is site-wide, so any active plugin can read it. Treat it like SMTP or payment credentials: one key per site, a spending limit at the provider, and rotation the moment you suspect a plugin.
The AI plugin has two opt-in experiments worth enabling if keys must live in the database: Key Encryption (libsodium encryption at rest) and Connector Approvals (plugins and themes need an administrator's approval to use your connectors).
What it costs
WordPress and the official plugins are free; the provider bills per token. An excerpt for a 1,500-word post is roughly 2,000 input tokens and under 100 output: about $0.0002 on Claude Haiku 5.5 ($0.10/$0.50 per million tokens) or half a cent on Sonnet 5.5 ($2/$10). Surprise bills come from automation: a feature that runs on every comment, a bulk alt-text job over 8,000 images, an agent that reads fifty posts before one change. Set a monthly cap before enabling anything that runs without a click.
Where your content goes
Every AI Client call sends content to a third party: drafts, comments, customer names, whatever the feature puts in its prompt. Check the provider's retention terms and your client contracts or DPA before enabling features that touch personal data. For sites that must not use AI there is a kill switch: define( 'WP_AI_SUPPORT', false ); in wp-config.php disables AI support in core, so prompts are refused and the AI provider connectors are not registered.
The Abilities API: the part agencies should plan around
An ability is a named, self-describing action: my-plugin/do-something, with a label, a description written for both humans and models, a JSON Schema for its input and output, an execute callback, and a required permission callback. Core registers a few of its own (core/get-site-info, core/get-user-info, core/get-environment-info), and plugins add the rest.
It gives agents a menu instead of a screwdriver. Without abilities, an agent has to drive wp-admin through a browser or guess at REST endpoints. With them, a WooCommerce extension can expose "list orders awaiting fulfilment" and a forms plugin "export last week's entries", and the agent sees what each needs, returns and changes.
Abilities are private by default. They become reachable over the REST API (/wp-json/wp-abilities/v1/) or MCP only when the developer marks them public.
Registering an ability
Here is a small plugin an agency might drop into wp-content/plugins/ to give an agent a read-only content report. It uses the real 6.9+ signature, wp_register_ability( string $name, array $args ), and the public flag added in 7.1.
<?php
/**
* Plugin Name: Agency Content Abilities
* Description: Read-only "stale drafts" report for AI agents.
* Requires at least: 7.1
*/
add_action( 'wp_abilities_api_categories_init', function () {
wp_register_ability_category(
'agency-content',
array(
'label' => __( 'Content reports', 'agency-abilities' ),
'description' => __( 'Read-only reports about site content.', 'agency-abilities' ),
)
);
} );
add_action( 'wp_abilities_api_init', function () {
wp_register_ability(
'agency-abilities/list-stale-drafts',
array(
'label' => __( 'List stale drafts', 'agency-abilities' ),
'description' => __( 'Lists draft posts not edited in the given number of days. Read-only; changes nothing.', 'agency-abilities' ),
'category' => 'agency-content',
'input_schema' => array(
'type' => 'object',
'properties' => array(
'days' => array(
'type' => 'integer',
'minimum' => 1,
'maximum' => 365,
),
),
'additionalProperties' => false,
'default' => array( 'days' => 30 ),
),
'output_schema' => array(
'type' => 'array',
'items' => array(
'type' => 'object',
'properties' => array(
'id' => array( 'type' => 'integer' ),
'title' => array( 'type' => 'string' ),
'modified' => array( 'type' => 'string' ),
),
),
),
'permission_callback' => function () {
return current_user_can( 'edit_others_posts' );
},
'execute_callback' => function ( $input ) {
$days = isset( $input['days'] ) ? (int) $input['days'] : 30;
$query = new WP_Query(
array(
'post_type' => 'post',
'post_status' => 'draft',
'posts_per_page' => 50,
'no_found_rows' => true,
'date_query' => array(
array(
'column' => 'post_modified',
'before' => $days . ' days ago',
),
),
)
);
return array_map(
function ( WP_Post $post ) {
return array(
'id' => $post->ID,
'title' => get_the_title( $post ),
'modified' => get_post_modified_time( 'c', true, $post ),
);
},
$query->posts
);
},
'meta' => array(
'annotations' => array(
'readonly' => true,
'destructive' => false,
'idempotent' => true,
),
// 7.1+: exposes the ability to REST and MCP clients.
// On 7.0, use 'show_in_rest' => true and 'mcp' => array( 'public' => true ).
'public' => true,
),
)
);
} );
When the ability runs, WordPress applies the schema default, validates the input, calls the permission callback as the current user, runs the callback and validates the output against the schema. An agent calling it as a subscriber gets an ability_invalid_permissions error, not your drafts.
What WordPress 7.1 added
The 7.1 release describes it as "a filterable execution lifecycle, custom validation, and shared discovery." In practice that means new hooks around WP_Ability::execute():
wp_ability_invokedfires on every call, before anything else, including calls that later fail. This is your audit hook.wp_pre_execute_abilitycan short-circuit a call and return a value directly. It skips validation and permission checks entirely, which is useful for caching, rate limiting and maintenance mode, and dangerous in a careless plugin. We covered that risk in our WordPress 7.1 update notes.wp_ability_permission_resultlets you layer extra rules on top of an ability's own permission check.wp_ability_execute_result,wp_ability_validate_inputandwp_ability_validate_outputlet you transform results and add validation.
Connecting Claude or another agent with the MCP Adapter
The MCP Adapter is an official WordPress.org plugin (version 0.7.0 as of October 2026, so still pre-1.0) that turns public abilities into Model Context Protocol tools. Its default server sits at /wp-json/mcp/mcp-adapter-default-server and gives the agent three tools: discover abilities, get ability info and execute an ability.
For a remote site, the documented route is the @automattic/mcp-wordpress-remote proxy with a WordPress application password. In Claude Desktop, Claude Code or any MCP client that uses this config format:
{
"mcpServers": {
"client-site": {
"command": "npx",
"args": ["-y", "@automattic/mcp-wordpress-remote@latest"],
"env": {
"WP_API_URL": "https://example.com/wp-json/mcp/mcp-adapter-default-server",
"WP_API_USERNAME": "ai-agent",
"WP_API_PASSWORD": "xxxx xxxx xxxx xxxx xxxx xxxx"
}
}
}
}
On a site where you have shell access, the adapter also runs over STDIO through WP-CLI: wp mcp-adapter serve --server=mcp-adapter-default-server --user=ai-agent. Either way, the agent acts as that WordPress user, and every ability's permission callback runs against that user's capabilities. That one fact is the whole security model, so choose the user carefully. Our step-by-step MCP setup guide walks through the client side in more detail.
What to turn on, and what to leave off
A sensible default for most business sites, based on what we see go right and wrong:
Turn on
- One provider connector, with the key in an environment variable and a monthly spending cap.
- Per-click editor helpers from the AI plugin: alt text, excerpts, titles, meta descriptions. A person reviews every output before it publishes.
- Read-only abilities, exposed to an agent on staging first.
Leave off for now
- Features that act on content automatically, such as the AI plugin's Comment Moderation or Editorial Updates (which applies editorial suggestions to posts), until you have watched their output on staging. The AI plugin labels itself experimental and its own FAQ recommends testing on staging first.
- Destructive abilities (anything that deletes, publishes, changes users or touches orders) exposed over MCP on production.
- Connectors on sites that handle health, legal or financial data, until the client approves the provider's data terms.
- Multiple provider plugins "just in case." Each one is more code with access to your keys.
Security and governance
Every ability is plugin code an agent can trigger, and plugins are where WordPress gets hurt: Patchstack recorded 7,966 new WordPress vulnerabilities in 2024, 96% of them in plugins.
Capability checks. Never ship '__return_true' as a permission callback for anything beyond public, harmless data. Match the capability to the action: edit_others_posts to read other people's drafts, manage_woocommerce for order data, manage_options for site configuration.
Who runs abilities. Create a dedicated user (for example ai-agent) with the lowest role that covers the abilities you want, issue it an application password, and revoke that password when the engagement ends. Never point an agent at an administrator account because it's convenient.
Logging. On 7.1, a few lines give you an invocation log and stop low-privilege users from spending your AI budget:
// Log every ability call, including denied ones.
add_action( 'wp_ability_invoked', function ( string $ability_name, $input, WP_Ability $ability ) {
error_log( sprintf( '[ability] %s by user %d', $ability_name, get_current_user_id() ) );
}, 10, 3 );
// Only users who can edit posts may trigger AI Client prompts.
add_filter( 'wp_ai_client_prevent_prompt', function ( bool $prevent ) {
return $prevent || ! current_user_can( 'edit_posts' );
} );
Test that filter against any AI feature that runs from WP-Cron, where there is no logged-in user. The AI plugin also has an AI Request Logging feature for prompt-level visibility.
Key handling. Environment variables or constants, never the database on shared or multi-admin sites. Separate keys per client site so one compromise doesn't spend every client's budget. Rotate keys after removing any plugin you no longer trust.
Review what's exposed. Before connecting an agent, run the adapter's discover tool or wp_get_abilities() in wp shell, and check each public ability's permission callback.
Performance and hosting implications
AI calls are outbound HTTP requests made inside a PHP request. The AI Client's default timeout is 30 seconds (filterable with wp_ai_client_default_request_timeout), and while a request waits on the provider, it holds a PHP worker. A few editors clicking "generate" is nothing. A plugin that calls a model during front-end page loads, or a bulk job that fires hundreds of calls, can tie up workers and slow the whole site.
MCP traffic is authenticated REST that bypasses page cache, so every agent call hits PHP and the database; on a small shared plan a session can look like a traffic spike. Batch bulk AI jobs through WP-Cron, keep heavy agent work on staging, use Redis object caching, and watch PHP worker saturation for a week after enabling anything new. Our platform runs NGINX, PHP 8.5 and Redis on Google C3D machines, and we still stage AI plugins before production.
Rollout checklist
- Update to the latest 7.1.x release (7.1.3 as of October 13, 2026) on staging.
- Decide per site whether AI is allowed at all. If not, set
WP_AI_SUPPORTtofalseand stop here. - Pick one provider, create a site-specific key with a spending cap, and set it as an environment variable or constant.
- Install the provider plugin and the AI plugin; enable only per-click features.
- Turn on Key Encryption and Connector Approvals if any key lives in the database.
- Add the invocation log and the prompt gate above, or your equivalent.
- Audit registered abilities and their permission callbacks; expose only read-only ones at first.
- Create a dedicated agent user and application password, then connect the MCP Adapter on staging.
- Watch PHP workers, error logs and the provider bill for a week, then promote to production.
Keep Reading on TopSyde
- Control WordPress from Claude: MCP server setup guide
- What changed in WordPress 7.1, including wp_pre_execute_ability
- WordPress staging environments
- MCP explained for product builders
- Managed WordPress hosting for agencies
Frequently Asked Questions
Does WordPress 7 include AI features out of the box?
No. Core includes the AI Client, the Connectors screen and the Abilities API, which are infrastructure. Alt text, excerpts, title suggestions and comment moderation come from plugins like the official AI plugin, and only work once you add a provider plugin and an API key.
Is it safe to store AI API keys in Settings > Connectors?
It works, but keys saved there are unencrypted in the database (masked only on screen). On production, set ANTHROPIC_API_KEY (or your provider's equivalent) as an environment variable or wp-config.php constant, which WordPress checks first. Otherwise, enable the AI plugin's Key Encryption experiment and cap spending at the provider.
What is the difference between the Abilities API and the MCP Adapter?
The Abilities API is in core (since 6.9) and lets plugins register actions with schemas and permission checks. The MCP Adapter is a separate official plugin that publishes public abilities as MCP tools for agents like Claude or Cursor. Abilities work without MCP; MCP needs abilities to offer anything.
Can an AI agent break my site through MCP?
It can do whatever your exposed abilities allow, as the user it connects as. Start read-only, use a dedicated low-privilege user with its own application password, log calls with wp_ability_invoked, and test destructive abilities on staging. Watch for plugins using wp_pre_execute_ability, which bypasses permission checks.
Can I turn AI off completely in WordPress 7?
Yes. Add define( 'WP_AI_SUPPORT', false ); to wp-config.php. AI Client prompts are then refused and the AI provider connectors are not registered. The wp_supports_ai filter does the same per request. The Abilities API keeps working, since it isn't tied to a provider.
Topics
Founder & Lead Developer
20+ years full-stack development, WordPress, AI tools & agents
Colton is the founder of TopSyde with 20+ years of full-stack development experience spanning WordPress, cloud infrastructure, and AI-powered tooling. He specializes in performance optimization, server architecture, and building AI agents for automated site management.
