Discoverable
An agent reads the registry and learns what a site can do. It does not need a hand-written list of endpoints supplied up front.
New in WordPress 6.9
The WordPress Abilities API, explained
It is the standard registry, new in WordPress 6.9, that lets any plugin publish typed, permission-checked abilities. This guide covers what it is, why it matters for AI agents, how a plugin registers one, and how Agent Abilities builds on it.
Summary and contents
The short version
The WordPress Abilities API lets plugins and core register named, typed, permission-checked units of work, so AI agents get one discoverable catalog of what a site can do instead of a pile of ad hoc endpoints.
- In one line
- A typed, permission-checked catalog of things a WordPress site can do.
- Added in
- WordPress 6.9.
- An ability has
- A name, a schema, a permission check, and an execute callback.
- For AI agents
- Exposed as MCP tools through the official adapter.
What the WordPress Abilities API is
A standard registry, added in WordPress 6.9, where plugins and core declare what a site can do as named, typed, permission-checked abilities.
Before this, every plugin that wanted to expose functionality reached for its own REST route, its own arguments, and its own way of checking who was allowed. There was no shared way to ask a site, in one place, what it could actually do. WordPress 6.9 added the Abilities API to fix that: a single registry that any plugin or core itself can register against.
An ability is a self-describing unit of work. It carries its own identifier, a plain-language description, a schema for its input and output, and two callbacks: one that decides whether a caller is permitted, and one that does the work. Because the description is structured, a program can read the registry and understand the site without a human writing an integration by hand.
What every ability carries
A name
A namespaced identifier such as my-plugin/get-latest-posts, unique across the whole site.
A label and description
Human-readable text, so a person or an agent can tell what the ability does before calling it.
Input and output schema
JSON Schema that describes the arguments the ability takes and the shape it returns. Typed, not guesswork.
A permission callback
Runs before the work does and decides whether this caller is allowed. This is where authorization lives.
An execute callback
The code that actually does the work and returns a result, or an error the caller can read.
Why it matters for AI agents
A registry of typed, permission-checked abilities is something an agent can reason about safely, which raw REST endpoints are not.
Point an AI agent at a plain REST API and it has to be told, in advance, which routes exist, what each one expects, and whether calling it is even allowed. The Abilities API turns that around. The site describes itself, the description is machine-readable, and the permission check is part of the definition rather than an afterthought. Three properties do the heavy lifting.
Typed
Each ability describes its own input and output with JSON Schema, so a client knows the exact shape of a call and its result.
Permission checked
A permission callback is part of the definition, so authorization is built in rather than bolted on after the fact.
Those three properties are what the Model Context Protocol builds on. An agent can discover what a site offers, read the shape of each call, and count on authorization running before anything happens. That is a much safer starting point than handing an agent a list of open endpoints.
How a plugin registers an ability
Hook into the wp_abilities_api_init action and call wp_register_ability with a name and an array of arguments, including the two callbacks that carry the weight.
Registration is a small amount of PHP. The example below declares an ability that returns recent posts. The permission callback decides who may run it, and the execute callback does the work. Everything else is metadata that makes the ability discoverable and typed.
add_action( 'wp_abilities_api_init', function () {
wp_register_ability( 'my-plugin/get-latest-posts', array(
'label' => __( 'Get latest posts', 'my-plugin' ),
'description' => __( 'Return the most recent published posts.', 'my-plugin' ),
'category' => 'my-plugin',
'input_schema' => array(
'type' => 'object',
'properties' => array(
'count' => array( 'type' => 'integer', 'default' => 5 ),
),
),
'output_schema' => array( 'type' => 'array' ),
'permission_callback' => function () {
return current_user_can( 'edit_posts' );
},
'execute_callback' => function ( $input ) {
$count = isset( $input['count'] ) ? (int) $input['count'] : 5;
return get_posts( array( 'numberposts' => $count ) );
},
) );
} );Illustrative and trimmed. It is faithful to the real function: registration runs on the wp_abilities_api_init action, and wp_register_ability takes a namespaced name plus label, description, category, input and output schema, a permission callback, and an execute callback. A production ability also registers its category and can add annotations. The official WordPress documentation carries the full surface.
From abilities to agent tools
The Abilities API is the registry on the WordPress side. MCP is how an external AI client discovers and calls those abilities, through the official MCP Adapter.
The two are separate jobs. The Abilities API standardizes how a site declares what it can do. The Model Context Protocol standardizes how an AI client talks to tools. The official MCP Adapter bridges them: it reads the registry and presents each registered ability as an MCP tool, so an agent calls a WordPress ability exactly as it would call any other tool.
The Abilities API
The registry inside WordPress 6.9. Plugins and core register abilities here.
The MCP Adapter
The official adapter maps each registered ability to an MCP tool an agent can call.
Your AI client
Connects in, discovers the tools it is allowed to see, and calls them over MCP.
Agent Abilities sits at the last step. It builds on the WordPress 6.9 Abilities API and the official MCP Adapter, so there is no custom transport in the path, and it adds a governance layer around every ability before an agent can reach it.
How Agent Abilities uses the Abilities API
Two ways: it ships its own catalog of governed abilities, and it can bridge abilities that your other active plugins register through the same API.
Its own governed catalog
The plugin registers 153 abilities of its own (83 across WordPress core plus 70 from auto-detected integrations). Every one is off until you enable it and capped at the capabilities of the WordPress account the agent connects as.
Browse the catalogAbilities from other plugins
Because any plugin can register abilities through the same API, the plugin can bridge the ones your other active plugins declare and expose them as governed MCP tools, off by default, held to the same rules as its own.
How bridging worksThe point of the wrapper is governance, not tool count. Whether an ability is one of the built-in catalog or bridged from another plugin, it runs under the same controls: nothing is exposed until you turn it on, the agent connects as a real scoped user rather than an admin key, the capability is re-checked before every call, and each call is written to an audit log in your own database, denials included. That combination is what makes it a governed WordPress MCP server rather than a raw bridge to your site.
Off by default
Nothing is exposed until you enable it, and updates never silently widen access.
Least privilege by design
The agent connects as a real WordPress user, never an admin-equivalent key. It takes the capabilities of whichever account approves the connection, so approve while logged in as the account you want the agent to be. With an Application Password you pick that account up front.
Two-layer capability gating
A connection only sees the tools its user can call, and every call re-checks that capability before it runs.
Honest audit log
Every call is recorded, denied attempts included, with the principal and the argument keys, never the values. It lives in your own database.
Frequently asked questions
Direct answers to the questions people ask about the WordPress Abilities API.
What is the WordPress Abilities API?
It is a standard registry, added in WordPress 6.9, where plugins and core register abilities: named units of functionality, each with a typed input and output schema, a permission check, and an execute callback. Anything that reads the registry gets one consistent, discoverable list of what a site can do.
Which WordPress version added the Abilities API?
It arrived in WordPress 6.9. Any site on that release or later has the registry available for plugins to register against.
How is the Abilities API different from the REST API?
The REST API exposes raw endpoints you have to know in advance. The Abilities API publishes typed, self-describing abilities with a permission check built in, so a client can discover what exists, read the shape of each call, and know the request will be authorized before it runs.
Do I need to write code to use it?
Not to consume it. Install a plugin that registers abilities, such as Agent Abilities for MCP, and you get a working catalog without touching code. Writing your own ability is a small amount of PHP: one wp_register_ability call with a permission callback and an execute callback.
How does MCP relate to the Abilities API?
The Abilities API is the registry on the WordPress side. MCP, the Model Context Protocol, is the language AI clients speak. The official MCP Adapter maps registered abilities into MCP tools, so an agent discovers and calls them the same way it calls any other tool.
Can I expose abilities that other plugins register?
Yes. Because any active plugin can register abilities through the same API, Agent Abilities can bridge the ones your other plugins declare and expose them as governed MCP tools, off by default until you enable each one. The bridge guide covers how that works.
Put the Abilities API to work, governed.
Install Agent Abilities for MCP, keep everything off, and turn on one ability at a time. Requires WordPress 6.9+ and PHP 7.4+. Free on WordPress.org.
Built on open standards. Nothing leaves your site without you.