The WordPress Abilities API: What It Is and Which Plugins Are Integrating

The WordPress Abilities API is a core registry that lets plugins, themes, and WordPress itself declare what they can do in a format other software can read, validate, and execute. It shipped in WordPress 6.9 on December 2, 2025, and WordPress 7.0 added a JavaScript counterpart for client-side abilities. If you have read that the Abilities API is a WordPress 7.0 feature, the version is off by one: the PHP registry, the REST endpoints, and the first core abilities all landed in 6.9.

The practical effect is that an AI agent, an automation tool, or another plugin can ask a site what it is capable of and get back a structured list: names, human-readable descriptions, JSON Schema definitions for input and output, and a permission rule for each entry. Before this, discovering what a given WordPress install could do meant reading plugin source code, guessing at REST routes, or reverse-engineering AJAX handlers. This post covers what an ability actually is, how one gets registered, how the API relates to the Model Context Protocol, which plugins have shipped integrations, the security model, and an honest accounting of what is in core versus what is still a separate project.

What counts as an ability

An ability is a self-contained unit of functionality with a defined contract. Per the Abilities API handbook on developer.wordpress.org, each one has a namespaced name in the pattern namespace/ability-name, and requires a label, a description, exactly one registered category and an execute callback. A permission callback, JSON Schema definitions for input and output, and a meta array are all optional, though shipping an ability without a permission callback is a decision rather than a default.

Two design choices matter more than they look. First, schemas are mandatory whenever there is a value to pass or return, and WordPress validates against them automatically. A malformed input never reaches your callback. Second, abilities carry semantic annotations: readonly, destructive, and idempotent. Those are hints for tooling rather than enforcement, but they are what lets a client decide whether an operation is safe to retry or needs a confirmation step.

Categories are not decoration either. Every ability must belong to a registered category, and categories have to exist before the abilities that reference them. Registration order is enforced through two separate hooks, which is a small friction point that trips up first-time implementers.

The problem it was built to solve

The WordPress AI Team framed the case plainly when it announced the project in July 2025: a typical site runs dozens of plugins, and there is no standardized way for any of them to express what they can do. An assistant has no systematic route to discover that the backup plugin can create snapshots or that the SEO plugin can analyze content. WordPress has never forced a convention for public APIs, so the available patterns range from action hooks to global functions to custom REST routes to extensible classes, often several at once in the same plugin.

Worth noting: the initiative is filed under AI Building Blocks, but the AI framing undersells the scope. The same registry is being wired into the Command Palette and the Workflows tooling in Gutenberg. Plugin-to-plugin interoperability is a real use case that has nothing to do with language models. Reading it purely as an AI feature is a common misreading.

Registering an ability, conceptually

The pattern is deliberately close to how WordPress developers already register post types and blocks. You hook wp_abilities_api_categories_init to declare a category, then hook wp_abilities_api_init and call wp_register_ability() with a name and a configuration array. Calling it outside that hook triggers a _doing_it_wrong() notice and the registration silently fails.

add_action( 'wp_abilities_api_init', 'my_plugin_register_abilities' );

function my_plugin_register_abilities() {
    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'            => 'site',
            'input_schema'        => array(
                'type'       => 'object',
                'properties' => array(
                    'post_type' => array( 'type' => 'string', 'default' => 'post' ),
                ),
            ),
            'output_schema'       => array( 'type' => 'integer' ),
            'execute_callback'    => 'my_plugin_get_post_count',
            'permission_callback' => function () {
                return current_user_can( 'read' );
            },
            'meta'                => array( 'show_in_rest' => true ),
        )
    );
}

The description field carries more weight than it does in most WordPress APIs. It is what an agent reads to decide whether this ability is the right tool for a request, so a vague description is a functional defect, not a documentation nit.

From there, PHP code fetches and runs the ability with wp_get_ability( 'my-plugin/get-post-count' )->execute( $input ). Setting meta.show_in_rest to true exposes the same ability at /wp-json/wp-abilities/v1/abilities/{name}/run, with the permission callback still enforced. WordPress 7.0’s client-side packages, @wordpress/abilities and @wordpress/core-abilities, mirror the same surface in JavaScript and are enqueued on every admin page by default, so server-registered abilities are callable from editor code without any extra wiring.

How this connects to MCP and AI agents

The Abilities API is protocol-agnostic on purpose. It describes what a site can do; separate adapters translate that description into whatever wire format a given client speaks. The WordPress MCP Adapter is the first of those, turning registered abilities into Model Context Protocol tools and resources so assistants like Claude and ChatGPT can discover and invoke them. The AI team has been explicit that other adapters could follow for protocols that do not exist yet, which is the main argument for the indirection.

That layering is the useful mental model. Abilities are the capability contract. MCP is one transport. AI agents are consumers that pick tools off the resulting menu. The registry sits underneath all of it and does not care which one is asking, which is also why the Command Palette can use the same entries. It is a different layer from the AI provider plumbing that arrived with WordPress 7.0, covered in our piece on the 7.0 AI integration layer: that side handles calling models, this side handles exposing your site to them.

Which plugins are actually integrating

WordPress core ships three abilities of its own, all read-only: core/get-site-info, core/get-user-info, and core/get-environment-info. That is the entire core surface. It is a foundation, not a feature set.

WooCommerce is the most substantive first-party adopter. WooCommerce 10.9, released June 23, 2026, introduced seven canonical domain abilities covering product query, create, update and delete, order query, order status updates, and order notes. The team deliberately walked back an earlier approach that wrapped REST endpoints one-for-one, on the reasoning that a REST mirror adds a second name and schema to maintain without adding a capability. The older WooCommerce-specific MCP endpoint is now a deprecated transition path. A follow-up in June 2026 extended the registration pattern to WooCommerce extensions covering subscriptions, payments, shipping, and marketing.

Jetpack shipped a dedicated AI settings screen in version 15.8 with MCP access off by default, granular read and write toggles by content category, per-action confirmation on writes, and an activity log. Jetpack Forms abilities are on for every site; connection status, sitemaps, shortlinks, and newsletter data sit behind a jetpack_wp_abilities_enabled filter that a developer has to flip. MCP access on self-hosted sites requires a paid Jetpack plan.

Advanced Custom Fields exposes field groups, post types, and taxonomies as abilities, which we covered in the ACF 6.8 release recap.

Then there is the bridge tier, and it is worth being precise about it. Plugins like Enable Abilities for MCP, at over 1,000 active installs, register roughly 58 abilities on behalf of software that has not adopted the API itself, including Yoast SEO, Rank Math, SEOPress, The Events Calendar, and JetEngine. If you see a claim that a given SEO plugin "supports abilities," check whether that support is first-party or a third party writing to its meta keys. The distinction matters for who is responsible when a schema changes.

Permissions, and where the risk actually sits

Every ability carries its own permission_callback, checked before execution in PHP, over REST, and through MCP alike. REST access requires an authenticated user and supports the standard WordPress authentication methods, with application passwords being the practical choice for external clients. Schema validation rejects unknown fields and out-of-range enum values before any callback runs. On the REST side the HTTP method is derived from the annotations: read-only abilities use GET, destructive idempotent ones use DELETE, everything else POST.

The honest caveat is that none of this is stronger than the implementer’s judgment. WordPress does not require a real capability check; the official tutorial on the WordPress developer blog uses __return_true as its permission callback. An ability is only as safe as the callback its author wrote, and an application password issued to an agent carries the full capabilities of the user it belongs to. Treat an admin-level application password handed to an external assistant as an admin credential, because that is exactly what it is. WooCommerce’s choice to make product deletion a soft delete unless force: true is passed is the kind of defensive default worth copying.

An honest status check

Shipped and in core: the PHP registry, the REST endpoints under wp-abilities/v1, the registration and execution hooks, and three read-only core abilities, all as of 6.9. The JavaScript packages and automatic admin enqueueing followed in 7.0.

Not in core: the MCP Adapter is a separate project, distributed both as a Composer package and as an installable plugin from its GitHub releases page, which is why WooCommerce vendors it rather than relying on a core service. The WebMCP work that the client-side API was partly built for is still in progress. WordPress 7.1, which releases August 19, extends the API rather than replacing it: the July 31 dev note adds wp_ability_validate_input, wp_ability_validate_output and wp_ability_invoked hooks, five new fields plus a fields parameter on core/get-user-info, and type coercion for REST query-string input. Separately, a July merge proposal to add three read-only core abilities, core/read-settings, core/read-content and core/read-users, did not land in 7.1 and was retargeted to the 7.2 milestone on July 14 after feedback that they needed more testing.

The skeptical read deserves airtime. A commenter on the original 6.9 dev note argued the whole thing is essentially a way to register functions for AI, that the surrounding WordPress AI classes are limited, and that most teams will keep using custom solutions. That is a fair description of where adoption stood at launch. What has changed since is that WooCommerce, Jetpack, and ACF have all shipped real integrations, and the value of a registry is cumulative: it is close to worthless with three entries and genuinely useful with three hundred. Whether it gets there is an ecosystem question, not a core-engineering one.

For most site owners the near-term answer is straightforward. If you run WooCommerce or Jetpack, you already have abilities registered whether or not you have connected an agent, and the settings screens are worth an audit. If you build plugins, the registration cost is low and the Composer package works back to pre-6.9 installs. If you are evaluating whether to connect an assistant to a production site, the permission model is sound in design and only as good as the weakest ability registered on your install.

Frequently Asked Questions