If you’ve spent any time automating WordPress, you’ve met all three of these tools:
If you’re like most developers, you’ve probably wondered which one you’re actually supposed to reach for. Most people trip up by treating them as competitors, as if choosing WP-CLI means turning your back on REST. That’s the wrong mental model, and it leads to a lot of wasted effort reinventing one layer inside another.
Think of them as layers rather than rivals. Each one sits at a different distance from your site and answers to a different kind of caller. WP-CLI lives on the server. The REST API lives on the wire. The Abilities API lives one level up again, where AI agents decide what to do.
Once you see where each one fits, the “which should I use” question mostly answers itself. Here’s how the three line up, and how to choose between them on any given task.
The 3 Interfaces at a Glance
Before going into the detail, here’s a summary of how they line up:
| Interface | How it reaches WordPress | Who calls it | What it is great at |
|---|---|---|---|
| WP-CLI | PHP, directly on the server (or over SSH) | You, scripts, cron, an agent with shell access | Bulk operations, migrations, deploys, maintenance |
| REST API | HTTP requests to wp-json | Browsers, mobile apps, external services, headless front ends | Reading and writing content from anywhere |
| Abilities API | Named PHP capabilities, exposed over REST and MCP | AI agents and the tools that orchestrate them | Giving agents a safe, described set of actions |
Keep that table in mind as we walk through each one. Here we go.
WP-CLI: The Command Line on the Server
WP-CLI runs PHP straight against your install. Think of wp post create, wp plugin update, wp search-replace, and wp db export. It assumes you, or a script acting as you, are on the server or can SSH in. There is no HTTP round trip and no auth token to manage, because you already have shell access to the box.
That makes it the fastest way to do something to a site you control. Migrating a thousand posts, swapping a domain across the database, running scheduled maintenance, or scripting a deploy. All of this is WP-CLI’s home turf, and nothing else comes close on raw speed.
That strength comes with a price, though. You need shell access since WP-CLI is not how a browser, a phone app, or a remote service talks to your site, and it never will be. It’s the tool you reach for when you are the one in the driver’s seat.
If you’re leaning on it heavily, it pairs naturally with a workflow where you rarely open wp-admin at all. Plenty of developers now run their sites almost entirely from the terminal and a headless front end, and WP-CLI is what makes that a comfortable process.
REST API: WordPress Over HTTP
The REST API turns your site into something any HTTP client can read and write. Endpoints live under /wp-json/wp/v2/, you authenticate with application passwords, cookies and nonces, or OAuth, and from there a browser, a mobile app, or an external service can fetch and update content from anywhere on the internet.
This is the layer that decoupled WordPress runs on. A headless front end built in Astro, Next.js, or anything else pulls its content over REST, a mobile app posts through it, and a third-party integration syncs through it. If the caller is off-server, REST is almost always how it gets in.
If you are new to it, we have a friendly introduction to the WordPress REST API that covers the basics.
There is a subtle but important limit with REST though. It exposes your resources, posts, users, taxonomies, settings, and leaves it to the caller to know which endpoints exist and how to assemble the right request. It describes what your data is, not what someone is trying to do with it, so for a human developer reading the docs, that’s fine, but for an AI agent, it’s a lot to figure out.
Abilities API: A Capability Layer for AI Agents
The Abilities API is the newest of the three. It landed in WordPress core in WP 6.9, with a plugin available for earlier versions, and it solves exactly the problem REST leaves open. How does an AI agent know what it is allowed to do on your site?
Instead of exposing raw resources, the Abilities API lets a plugin or theme register named abilities. Each one is a discrete, described capability with a stable ID, a human-readable label, a description, input and output schemas, and a permission check. You register categories first on the wp_abilities_api_categories_init hook, then the abilities themselves on wp_abilities_api_init:
add_action( 'wp_abilities_api_init', function () {
wp_register_ability( 'my-plugin/publish-draft', [
'label' => __( 'Publish a draft', 'my-plugin' ),
'description' => __( 'Publishes an existing draft post by ID.', 'my-plugin' ),
'category' => 'my-plugin',
'input_schema' => [ /* JSON Schema for the expected input */ ],
'output_schema' => [ /* JSON Schema for the result */ ],
'permission_callback' => 'my_plugin_can_publish',
'execute_callback' => 'my_plugin_publish_draft',
'meta' => [ 'show_in_rest' => true ],
] );
} );Set meta.show_in_rest to true and the ability surfaces under wp-json/wp-abilities/v1/abilities, ready for clients to discover. On the JavaScript side, you consume abilities through the @wordpress/abilities package.
The difference that matters most here is that the REST API describes your data, while the Abilities API describes what an agent is allowed to do with it.
An ability says, in effect, “this is a thing you can do, here is what it needs, here is who is permitted to run it”. That is precisely the contract an AI agent needs to act safely, without you hand-wiring and documenting every endpoint it might touch. It’s also why the Abilities API is becoming the backbone of multi-agent setups on WordPress, where several agents need a shared, trustworthy vocabulary of actions.
How the Three Stack Together
As I said earlier, these layers build on one another.
Abilities are frequently exposed over the REST API, so the Abilities layer often sits on top of REST rather than beside it. REST, in turn, runs on the same PHP that WP-CLI drives directly. Underneath all three is the same WordPress core, the same database, the same functions.
So the real question is never “which one is best?” It’s “how far from the site does my caller live, and how much does it need spelled out?” The closer and more trusted the caller, the lower you can go. The more autonomous and the further away, the higher you climb.
When to Reach for Each
A quick decision guide for everyday work:
- You are doing something to a site you control, in bulk, and you want it fast. Reach for WP-CLI. Migrations, deploys, scheduled jobs, and database surgery all apply.
- A browser, app, or off-server service needs to read or write content. Reach for the REST API. Headless front ends, mobile apps, and integrations are some examples.
- An AI agent should be able to act on your site without breaking it, so reach for the Abilities API. Register the actions you want to allow, with permissions and schemas, and let the agent discover them.
Most real projects use more than one and they’re complementary by design, so the best setups lean on all three at once.
A Setup That Uses All Three
To give you a better idea of how that can work, here is how the three fit together on my own sites.
My publishing and operations run on WP-CLI over SSH. New posts, media imports, plugin updates, cache flushes… they all happen from the terminal, and I almost never open wp-admin. It’s faster, scriptable, and an AI assistant with shell access can drive it directly.
The front end is headless and reads over the REST API. An Astro site pulls content from WordPress through wp-json and serves it as fast static pages, so visitors never touch a WordPress theme. WordPress becomes the engine and the REST API is the pipe between it and the front end.
Agent-facing features go through the Abilities API, so where I want an AI agent to handle a scoped task, the relevant plugin registers an ability for it, with a permission check and a schema, rather than handing the agent shell access or a pile of raw endpoints to reverse-engineer.
Each layer does the job it is genuinely best at and none of them is “the” way to talk to WordPress. Trying to force one to do another’s job is where the pain usually starts.
If you are weighing up whether to bring in a developer for this kind of architecture, this comparison of an AI website builder versus a developer is a useful companion read.
Pick the Layer, Not the Winner
WP-CLI, the REST API, and the Abilities API are three layers of the same stack, each meeting a different caller where it lives. Stop asking which one wins, and start asking which layer your caller belongs to. The decision gets a lot easier from there.
How are you wiring AI agents into your WordPress stack, with the Abilities API, custom REST routes, or something else entirely? Let us know in the comments.
