WordPress and AI in 2026: The Abilities API, the MCP Adapter and AI in Core

by Francis Rozange | Oct 2, 2026 | WordPress

In early October 2025, an option in AI Engine, an AI plugin then installed on more than 100,000 WordPress sites, placed its MCP server’s access key in the very address of its routes. Those routes showed up in the site’s public REST API index. On sites that had ticked that option, anyone could read the key, and that key opened the site with the administrator’s permissions.

That episode, fixed within a few weeks, sums up what is at stake right now. AI agents no longer just draft text: they can act on a site, create content, change settings, manage users. In 2025 and 2026, WordPress gained an official way to let them in. You still need to know what it is, what is really in core, and what is not.

This guide presents the building blocks created by the WordPress Core AI team: the Abilities API, the AI client, the connectors screen, the MCP Adapter and the AI plugin. For each one, its status in October 2026, what it changes for a site owner, and the security questions it raises.

What “AI in core” means in October 2026

Infrastructure, not features

The Abilities API arrived in WordPress 6.9, in December 2025. The AI client and the connectors screen arrived in 7.0, in May 2026. Version 7.1 refined the Abilities API. But a default install shows no visible AI feature, bundles no provider and contains no MCP server. The Core AI team said so itself in June 2026: there is still no visible AI in the default interface.

In other words, WordPress provides the plumbing, and plugins use it. Our guide to what changed in WordPress 7 places these building blocks within the full set of changes.

The four building blocks at a glance

  • The Abilities API: a registry of what a site can do, in core since 6.9.
  • The AI client and the PHP AI Client SDK: a single interface to query a model, in core since 7.0, with the connectors screen.
  • The MCP Adapter: a separate plugin, distributed from GitHub, that opens the site’s abilities to agents.
  • The AI plugin: the visible features, as experiments, in the WordPress.org directory.

The Core AI team and its roadmap

From formation to new leadership

The Core AI team was announced on May 27, 2025, with a plugin-first approach, like the Performance team before it. In July 2025, James LePage published its plan: an SDK to query models, the Abilities API, the MCP Adapter and an experimentation plugin. The stated ambition was that, from 7.0, anyone could use and build AI features.

On May 18, 2026, James LePage and Felix Arntz stepped back as co-leads, staying on as advisors, and Jason Adams took the lead of the team. The same message specified that the MCP Adapter and the AI plugin remain, for now, outside core.

7.2 and the new rule: prove before merging

The 7.2 roadmap, published on September 18, 2026, restates the cautious guidance that came out of the 7.1 cycle: an AI feature must demonstrate adoption and real-world value before being considered for core. All planned AI work, write abilities, an updated MCP Adapter, agent identity, will happen in the AI plugin, with no guarantee of landing in 7.2.

The Abilities API: describing what a site can do

Anatomy of an ability

An ability is a self-describing unit of functionality: a name, a label, a description, a category, a schema for the expected and returned data, an execution function and a permission check function. An agent, the AI client or another plugin can thus discover what the site can do, and call it cleanly.

Here is the example from the WordPress 6.9 developer note, condensed, with the 7.1 public flag and the read-only annotation added.

add_action( 'wp_abilities_api_categories_init', function () {
    wp_register_ability_category( 'content-management', array(
        'label'       => __( 'Content Management', 'my-plugin' ),
        'description' => __( 'Abilities for managing and organizing content.', 'my-plugin' ),
    ) );
} );

add_action( 'wp_abilities_api_init', function () {
    wp_register_ability( 'my-plugin/get-post-count', array(
        'label'               => __( 'Get Post Count', 'my-plugin' ),
        'description'         => __( 'Retrieves the total number of published posts.', 'my-plugin' ),
        'category'            => 'content-management',
        'input_schema'        => array( 'type' => 'string', 'default' => 'post' ),
        'output_schema'       => array( 'type' => 'integer' ),
        'execute_callback'    => function ( $input ) {
            return (int) wp_count_posts( $input ?? 'post' )->publish;
        },
        'permission_callback' => function () {
            return current_user_can( 'read' );
        },
        'meta'                => array(
            'public'      => true,
            'annotations' => array( 'readonly' => true ),
        ),
    ) );
} );

An ability must be registered on its dedicated hook; outside it, registration fails. Its name follows the namespace/ability-name form, in lowercase.

The REST API and HTTP methods

Exposed abilities are available under the wp-abilities/v1 REST namespace, always for an authenticated user. Core enforces a useful rule: an ability annotated as read-only is called with GET, a destructive and idempotent one with DELETE, the others with POST. A wrong method returns a 405 error.

To test the example ability, declared read-only, a GET call is enough, authenticated with an application password, with the input passed as a parameter.

curl -u 'USER:APP_PASSWORD' 'https://example.com/wp-json/wp-abilities/v1/abilities/my-plugin/get-post-count/run?input=page'

What 7.1 added

Version 7.1 unified exposure under a single flag, meta.public, made it possible to filter the list of abilities, and added filters across the whole execution cycle: before the call, on permissions, on the result. An action fires on every call, denied or not, which allows logging. The developer note insists on one point: exposure is not authorization, only the permission check protects.

The new filters also let you switch off an ability without removing it, during maintenance for example. This snippet, simplified from the 7.1 developer note, returns a 503 error for a single ability.

add_filter( 'wp_pre_execute_ability', function ( $pre, $ability_name ) {
    if ( 'my-plugin/sync-catalog' !== $ability_name ) {
        return $pre;
    }
    return new WP_Error( 'ability_temporarily_unavailable', __( 'Temporarily unavailable.', 'my-plugin' ), array( 'status' => 503 ) );
}, 10, 2 );

Who already registers abilities

Core only registers three, all read-only: site, current user and environment information. The abilities to read content and settings, proposed in July 2026, are only available in the AI plugin. WooCommerce 10.9, in June 2026, registers official abilities for products and orders, with product deletion going to the trash by default.

WooCommerce also offers, as a developer preview, an MCP integration that must be explicitly turned on. Its documentation requires an application password, never the account password or a WooCommerce REST API key, and warns that order and customer operations can expose personal data. Keep it for a copy of the store.

The AI client, the PHP SDK and the connectors screen

A single interface for every provider

Core’s AI client relies on a WordPress-independent SDK, PHP AI Client, wrapped in a WordPress-specific layer. A plugin states its model preferences, but it is the site owner, through the providers they have configured, who decides. The plugin first checks that a feature is available, without a paid call.

$builder = wp_ai_client_prompt( 'Summarize the benefits of caching in WordPress.' );
if ( $builder->is_supported_for_text_generation() ) {
    $text = $builder->generate_text();
    if ( ! is_wp_error( $text ) ) {
        echo wp_kses_post( $text );
    }
}

The developer note is explicit: never assume an AI feature is available just because WordPress 7.0 is installed. The standalone SDK has moved on since, with embedding generation for semantic search in July 2026, but core still bundles its version 1.3.1.

The connectors screen and where your key lives

The connectors screen, under Settings, features Anthropic, Google and OpenAI; each requires installing the provider’s plugin. The official plugins for these three providers each have more than 50,000 active installs in October 2026. Community connectors exist too, including Ollama for a local model, with no key.

The API key is looked up in an environment variable, then a PHP constant, then the database. Yet a key in the database is not encrypted, only masked on screen: it ends up in every backup and every copy of the site. Prefer a constant in wp-config.php or an environment variable. A Secrets API is proposed for 7.2.

Turning AI off where it does not belong

Two levers have existed since 7.0. This constant turns off AI support across the whole site.

define( 'WP_AI_SUPPORT', false );

More finely, the wp_ai_client_prevent_prompt filter blocks requests depending on the context, for example for any user who is not an administrator. On a business site bound by confidentiality rules, it is the first line of defense.

MCP and the MCP Adapter: letting agents in

MCP in brief

The Model Context Protocol is an open standard that lets an AI assistant use tools, read resources and follow request templates provided by a server. The connection runs either locally, through a program’s standard input and output, or remotely, over HTTP. The latest version of the specification is dated July 28, 2026.

The default server and its three tools

The WordPress MCP Adapter turns abilities into MCP tools. On activation, it creates a default server that exposes three generic tools: discover abilities, get the description of one of them, run it. Only explicitly public abilities are visible, and the execution tool rechecks the permissions of the ability being called.

Two checks run one after the other: the transport’s, which by default requires a logged-in user, then each ability’s. Locally, the adapter runs through WP-CLI, under a specific user’s identity, as our essential WP-CLI commands show.

wp mcp-adapter serve --server=mcp-adapter-default-server --user=mcp-agent

Here, mcp-agent stands for a dedicated account with limited permissions; the adapter’s documentation advises against running the server as an administrator unless necessary.

Connecting remotely

For an agent that does not run on the server, the adapter’s documentation uses a small local relay published by Automattic, which connects to the site over HTTP. It accepts OAuth 2.1, tokens or application passwords. But OAuth requires the site to have an authorization server: WordPress.com does, a standard WordPress install does not ship one. On a self-hosted site, the agent therefore connects in practice with an application password.

Version 0.6.1: still a developer tool

In October 2026, the adapter’s latest version is 0.6.1, released on August 13. It is downloaded from GitHub, not from the official directory, where publishing it is a goal of the 7.2 cycle. Support for the latest MCP specification is only described in an unreleased version 0.7.0. It is a tool to try on a copy, not to plug into production without precautions.

The AI plugin, formerly AI Experiments

What it does today

The official plugin, renamed simply AI in March 2026, has more than 50,000 active installs. It offers features you turn on one by one: generation of titles, excerpts, meta descriptions and alternative text, image generation and editing, comment moderation and replies, translation, content classification.

It requires at least one connector and your own API key; the plugin is free, model usage is billed by the provider. It only works with the block editor, and its own FAQ recommends testing it first on a copy of the site.

The governance features to turn on

Three experiments deserve to be turned on first: AI request logging, connector approvals, which let the administrator decide which plugins can use the configured providers, and encryption of keys at rest, which makes up for core’s limitation.

The plugin’s listing announces more features to come, including a playground, a writing assistant, an agent able to act on the site and task automation. None of that has shipped in October 2026: judge the plugin on what it does today, not on its list of intentions.

A glass door left ajar with a beam of light escaping

The real case: AI Engine and the MCP door left ajar

AI Engine, by Jordy Meow, is a chatbot and AI tools plugin that had more than 100,000 active installs in 2025. It was one of the first to offer an MCP server in WordPress. Its story, documented by Wordfence, by vulnerability registries and by the plugin’s own changelog, shows what is at stake when an agent gets the keys to a site.

May and June 2025: every logged-in user, a potential administrator

On April 30, 2025, AI Engine added MCP support, presented as a beta feature. It let an assistant such as Claude create users, change settings, and edit and delete posts. On May 21, István Márton, a researcher at Wordfence, found that access to the MCP server required only one thing: being logged in. A mere subscriber could reach it.

The optional key check could be bypassed by sending no key at all. With the MCP user management tools, a subscriber could promote themselves to administrator. One condition limited exposure: the developer tools and then the MCP module had to be turned on, and both were off by default. The vendor replied within the hour, and version 2.8.4 fixed it on June 18, 2025, by restricting access to administrators.

October 2025: the key in the public index

A few months later, a new option, off by default, placed the access key in the address of the MCP routes, for clients unable to send a header. But those routes were registered without being hidden from the public REST API index. On affected sites, any visitor could read the key, and that key authenticated as the site’s administrator.

According to Wordfence, the flaw was reported to it just one day after it was introduced, by Emiliano Versini, through its bug bounty program. Version 3.1.4 fixed it on October 19, 2025, by hiding the routes. Wordfence stressed that the fix only prevents further leaks, and that the only safe solution is to change the key. No exploitation was reported in the sources we read.

2026: three more fixes and a different model

In 2026, three more fixes touched the same area. In May, the OAuth sign-in the plugin had just added, in version 3.4.9, opened the MCP tools to any valid OAuth token without checking that its holder was an administrator: a subscriber could once again make themselves administrator, until version 3.5.0, released four days later.

Two more followed: MCP user management tools that did not check permissions properly on multisite, then keys visible to an editor in the page’s code. The plugin changed its approach: OAuth sign-in for desktop applications, with no shared key, an approval request before any change launched from its built-in workspace, and a refusal to run arbitrary PHP code, a feature it considers dangerous by nature.

What the official stack does differently, and what it still lacks

An MCP server in WordPress is a REST route: its permission check is its entire perimeter, and “logged in” is not a permission. A static key that grants administrator rights is an administrator password: anything that can display it, REST index, URL, log, is a leak. Since its March 2025 version, which predates both flaws, the MCP specification has required the access token to be sent in the Authorization header and forbidden putting it in the URL query string.

The official stack answers several of these points by design: abilities private by default, a permission check for each one, a double check in the adapter, sign-in under a real account. But it does not yet solve agent identity or limiting a key’s permissions. Even the official AI plugin published five security advisories, including an ability that let an author make the server query internal addresses.

Permissions and authentication for agents

Application passwords: practical, but unlimited

For a remote agent on a self-hosted site, the documented method is the application password, available since WordPress 5.6. It can be revoked at any time from the user’s profile, with the date and IP address of last use. But it carries all its user’s capabilities: the ability to limit its scope has been listed as future development since 2020, without arriving.

If you have no use for them, you can turn them off.

add_filter( 'wp_is_application_passwords_available', '__return_false' );

One dedicated user per agent, read-only first

The official WordPress developer blog states the rule: an MCP client acts as a logged-in user, so it is part of your application’s surface area. Create a dedicated account for each agent, with the lowest possible role, as our guide to WordPress user roles explains. On an HTTP endpoint exposed to the internet, favor read-only abilities, and monitor and log usage.

What the MCP specification says

The July 2026 MCP specification makes authorization optional, but recommends an OAuth 2.1-based flow for HTTP connections. It asks the application driving the agent to obtain the user’s explicit consent before calling a tool, and states that a tool’s annotations, such as “read-only”, should not be taken at face value if the server is not trusted. A well-designed agent therefore asks before acting.

On the WordPress side, the 7.2 roadmap plans an alert email when an application password is created, and re-authentication before sensitive actions. Neither has shipped in October 2026.

What can go wrong

  • An ability that fetches a URL: it can be used to query the server’s internal services.
  • An ability that writes metadata: in the AI plugin, it let an author delete other users’ media files.
  • Cost: a feature called without control consumes paid API credits.
  • Prompt injection: malicious content returned by an ability can hijack the agent; the core abilities proposal declares it out of scope.
  • No identity: an agent’s actions are attributed to the human whose credentials it borrows.

These risks add to the basic measures in our guide to WordPress security hardening.

AI on the hosting side

WordPress.com: read first, then write with approval

WordPress.com opened read-only MCP on its paid plans in October 2025, added OAuth 2.1 sign-in in January 2026, then write access in March 2026. The safeguards are explicit: every change requires your approval, new posts are created as drafts, deletions go through the trash where possible, with an extra confirmation for categories and tags, whose deletion is permanent, role permissions are respected, and each operation can be turned on separately.

Hosts as AI providers

In December 2025, the Core AI team published a call to hosts. In its view, the main barrier is that every user has to bring their own API key. It suggests that hosts register their own provider, so that plugin features work with no setup. WordPress.com and DreamHost were working in that direction, according to the team’s review, but no such offer was publicly documented at DreamHost at the time of writing.

WordPress VIP, WP Engine and Pressable

Since July 2026, WordPress VIP has offered secure MCP access, closed by default, with a call log and a global kill switch. WP Engine turns on by default a read-only MCP server over public content on the relevant plans, which you have to turn off if you do not want it. Pressable offers an MCP server for the hosting itself, able to run WP-CLI commands across several sites at once. Our comparison of WordPress hosting providers helps place these offers.

What to try today, what to wait for

Building block Status in October 2026 Try it? Condition
Abilities API Core since 6.9, refined in 7.1 Yes, for developers Real permission checks
AI client and connectors Core since 7.0 Yes Key outside the database
AI plugin Experimental, version 1.3 Yes, on a copy Logging and approvals on
MCP Adapter 0.6.1, outside the directory Locally or on a copy Dedicated account, read-only
Core write abilities Under discussion No Wait for 7.2 or later
Agent identity, scoped passwords Not shipped No Follow the roadmap
Secrets API Proposed for 7.2 No Constants in the meantime

Frequently asked questions

Do I need WordPress 7.0 to use AI?

For the AI client and the connectors screen, yes. The Abilities API has existed since 6.9; the official provider plugins install from 6.9, but only work there with the PHP AI Client package installed separately, which is a developer’s job. The AI plugin requires 7.0.

Does WordPress send my content to an AI by default?

No. Without a provider plugin, a key and a feature turned on, nothing leaves. You are the one who plugs in a provider and turns on features.

Is the MCP Adapter safe in production?

It is designed carefully, with abilities private by default and a double permission check, but it is still at version 0.x, outside the directory. In production, keep it for a dedicated account with limited permissions and read-only abilities.

Can I use a local model?

Yes, thanks to community connectors such as Ollama’s, which needs no key. The model then runs on your machine or your server.

Do application passwords limit what an agent can do?

No. They carry all their user’s capabilities. The account’s role sets the limit, hence the value of a dedicated account.

Conclusion

In October 2026, AI in WordPress is solid but discreet infrastructure: an Abilities API to describe what a site does, a provider-independent AI client, a connectors screen, a still young MCP Adapter and an experimentation plugin. Nothing turns itself on, and that is good news.

AI Engine’s story recalls what really matters when an agent acts on a site: permissions checked on every call, keys that do not leak, a dedicated account for each agent. Try things on a copy, read-only first, and wait for agent identity before trusting agents with write access in production.

Sources


LaFactory designs, builds and maintains WordPress and WooCommerce sites, and develops its own plugins. Talk to us about your WordPress project.

Francis Rozange

Former section editor at Libération, he runs LaFactory, an international web agency since 1996.

Cart