The WordPress Abilities API: What It Lets Software Do To A Client Site.

Short answer: the wordpress abilities api is a registry, introduced in WordPress 6.9, where plugins and core declare what they can do in a machine-readable schema. It is not a chatbot and it is not an AI feature. It is the list an agent reads to find out what a particular site permits, and that list is decided entirely by what is installed.

I read one on a live production site this week. Here is what is actually in there.

What it is, in core’s own words

The WordPress AI team describes the Abilities API as “a core WordPress API (introduced in 6.9) that creates a central registry of capabilities, making WordPress functions discoverable and accessible to AI agents, automation tools, and developers”.

An ability itself is defined as “a registered, self-documenting unit of WordPress functionality that can be discovered and invoked through multiple contexts (REST API, Command Palette, MCP). Includes authorization and input/output specifications”.

The phrase doing the work there is self-documenting. The site tells you what it can do, what each operation accepts, and what it returns, without anybody writing an integration guide.

A real WordPress Abilities API registry, read live

Everything else was registered by a plugin somebody chose to install.*

That distribution is the thing to internalise. What an agent can do to a WordPress site is not a property of WordPress. It is a property of that site’s plugin list.

Here is a single ability as the site publishes it:

requested. This is the difference between an agent guessing at an API and an agent reading a contract. Anything outside the schema is rejected before it reaches any code.*

The line core drew, and the line your plugins did not

Core is being deliberately careful here, and it is worth knowing why.

The AI team is implementing read-only abilities first, with management operations planned afterwards, on the reasoning that write operations “require more careful design and governance than retrieval capabilities.”

That caution does not extend to plugins, because it cannot. Any plugin may register any ability it likes.

plugin, are as powerful as SSH. That is not a criticism of the connector, which documents exactly what it does. It is the reason installing one is an agency decision rather than a technical detail.*

An agent connected to that site is not limited by the Abilities API. It is limited by whichever plugin registered the most dangerous ability, and by the capabilities of the user whose credential it holds.

What this changes for an agency

The genuinely useful shift is that you can now inspect this rather than trust a vendor’s description of it.

Before the Abilities API, “our tool integrates with WordPress” was a claim you either believed or did not. Now the site itself will tell you, in a schema, exactly what has been exposed on it.

PHP evaluation is not a limited integration, whatever the marketing says. It is full server access with a friendlier name.*

One practical habit: never hardcode an ability list. Ask the site every time. Plugins get added, updated and removed, and a list you cached in March describes a site that no longer exists.

There is a second habit worth building, and it comes from the same place as every other check on this blog: verify the revocation path before you rely on it. An application password is revoked from the user’s own profile screen, and the connection dies immediately. Test that once, on a site you control, so you know what it looks like. A safety mechanism nobody has ever exercised is a backup nobody has ever restored: a hope with a filename.

It is also worth being clear about what the registry does not tell you. It lists what a site can do. It says nothing about whether the code behind each ability is well written, or whether the plugin that registered it is still maintained. An ability exposed by a plugin that quietly left the directory is still discoverable, still invokable, and no longer receiving fixes.

Reading a registry yourself

The endpoint is public in the sense that it exists at a known path, though it requires authentication to read:

curl -s -u "USER:APPLICATION_PASSWORD" \
  https://example.com/wp-json/wp-abilities/v1/abilities \
  | python3 -c 'import json,sys
d=json.load(sys.stdin)
items = d if isinstance(d,list) else d.get("abilities",[])
print(len(items),"abilities")
for a in items: print(" ", a["name"])'

Two things to look for in the output. Group the names by their namespace prefix, because that tells you which plugin contributed what. Then read the description of anything whose name contains write, exec, eval, delete or update, because those are the ones that can change the site.

If the list surprises you, that is the point of reading it.

Where I think this goes

The interesting part is not that agents can now change WordPress sites. Software has been able to do that for twenty years through the REST API and WP-CLI.

The interesting part is that the site can now declare what it permits, in a form software can read, and that declaration can be audited by the person responsible for the site.

That is the piece agencies have never had. Not a promise that a tool behaves, but a list you can read before you connect it, and revoke afterwards without asking anybody.

Protuno connects to sites this way, and the same reasoning is why every agent carries a permission you set and why nothing writes without a proven restore point. Straight with you as on every post here: the Super Agents are built and named but not live yet. The free audit needs no connection at all and runs from a domain.

If you want to see this for yourself, the fastest route is a site you already control. Install a connector, request the abilities list, and read it. It is more informative than any integration page, and it is the same list an agent would read.

It also pairs well with knowing what PHP branch that site is on, because an agent is only ever as safe as the runtime underneath it.