From plugins to agents: the new WordPress architecture

Every few months someone declares WordPress dead. If WordPress is dead, plugins are dead too, and plugin companies certainly are. I run one, so I’d know.

And yet WordCamps are still full. What has changed is something most of us haven’t noticed: WordPress quietly gave plugins a new way to work with AI. It’s called the Abilities API, and it matters for every plugin on your site.

Your site already tells AI what it can do

Before you install a single AI plugin, your site already keeps a list of things an AI can do. It’s the Abilities API registry, and core has already put three entries in it:

core/get-site-info
core/get-user-info
core/get-environment-info
your-plugin/

Three entries, all from core. Is your plugin on the list?

Built four times, shared with nothing

Look at a typical site with a few AI plugins: security, SEO, forms, backups. Each one added AI on its own, with its own chat widget, its own assistant prompts and its own model picker. Some now ship their own MCP server that you connect one by one.¹And every one of them wants the same corner of the dashboard.

The same features, built four times and shared with nothing.

Register once, and every door opens

WordPress now has two registries in core. The Abilities API, in core since 6.9, answers one question: what can this plugin do? You register an ability once, and permissions run through WordPress and the logged-in user, not through auth you built yourself.

Then every door reaches it. The MCP Adapter turns your abilities into MCP tools, and the same ability answers over REST, WP-CLI and plain PHP. MCP is a door, not the thing you build.

Underneath sits Connectors, which answers a different question: whose API key do we use? A site owner adds the key once, under Settings › Connectors, and every plugin uses whichever provider they chose.²Connectors arrived in WordPress 7.0. Build on the AI Client, starting from wp_ai_client_prompt(), and your plugin never sees, stores or asks for a key.

Plugins

In core

Doors

Plugins register their abilities once, in core. Every door reaches them, and Connectors hold the keys.

One sentence, start to finish

This is a real run against our QA site, using BetterShield, a security plugin we built at Startise. I didn’t write the client.

Agent sessionBetterShield over MCP

Check my site and fix what's risky.

bettershield/get-security-postureread-only

Description: The security score, grade, and open findings for this site, each with a plain-language explanation.
Annotation: readOnlyHint: true

13 open findings. Most need a person to decide. A couple I can fix safely right now, starting with the dashboard file editor.

bettershield/propose-hardeningread-only

Description: Describes exactly what applying one protection would do to this site. Changes nothing.
Annotation: readOnlyHint: true

Disable the dashboard file editorDenies edit_plugins, edit_themes and edit_files for every role.Records the prior state in the undo ledger first.Reversible · sign-in unchanged

That's the plan. Want me to apply it?

Yes.

bettershield/apply-hardeningdestructive

Description: Applies one protection. A reversible protection is applied directly, and the answer carries the handle that puts it back.
Annotation: destructiveHint: true

Done. The file editor is off, and the undo is recorded.

You're the site owner.Send the request, watch the agent work, and decide when it asks.

It looked without asking, and it asked before changing anything. Nobody told it that in a prompt. The plugin told it.

Write the description for the AI that reads it

For years the description field was written for a person skimming an admin screen. Now a model reads it and decides, from that one sentence, whether to call you.

What most of us write

'Hardening.'

What an agent can act on

'Describes exactly what applying one protection would do to this site. Changes nothing.'

The second one says what it returns and ends with the two words that matter most. “Changes nothing” is what lets an agent use it without bothering the user.

Look freely, ask before touching

Every ability can be annotated as read-only or destructive. The proposal is read-only, so agents can call it as often as they like. The apply is destructive, so a good client stops and asks a person first.

Let agents look freely. Make them ask before they touch.

Never give an agent a single apply button. Split it into a read-only proposal that describes exactly what would change, and a destructive apply that only acts after a yes. Let the plan expire if nobody says yes. That’s how we build it in production.

Two things to get right

Annotations are a sign, not a lock. Marking an ability destructive asks a client to be careful; it can’t force it. Check for a confirmation in your own code before anything changes.

And keep keys out of the database. Keys saved from the dashboard sit in wp_options as plain text, so they travel with every export and backup. Put them in wp-config.php or a server environment variable instead. WordPress checks those first.

// wp-config.php: WordPress reads this before it looks in the database.
define( 'ANTHROPIC_API_KEY', '…' );

Try this tonight

If you were about to build an MCP server for your plugin, don’t. Register an ability. Start with one read-only ability for something your plugin already does; the MCP Adapter makes it a tool for any MCP client. The docs are at developer.wordpress.org/apis/abilities-api. Or ask your agent to do it. Seriously.

Register abilities, not servers.
Write descriptions for the AI.
Look freely. Ask before touching.
Use Connectors. Keep keys out of the database.

Nazmul Hasan Rupok

Founder and CEO of Startise. I write about building products and companies, and about software for AI agents.