Short answer
WordPress 7.0 shipped three AI building blocks in core: a provider-agnostic AI
Client, a Connectors screen for managing provider connections, and a client-side
counterpart to the Abilities API that arrived in 6.9. None of it calls any AI
provider until an administrator connects one. I went looking for what actually
exists on my own production site, from outside, before configuring anything —
and the most interesting thing I found was an endpoint that answered every
question honestly, including one answer most people would misread as a bug.
What did 7.0 actually ship?
The 7.0 “Armstrong” release
(May 20, 2026) is mostly known for the redesigned admin. The AI work is quieter
and, in the long run, probably bigger. Three pieces, per the
Field Guide:
- The AI Client — a provider-agnostic PHP API. A plugin calls
wp_ai_client_prompt()
and core routes the request to whatever provider the site has configured. The
plugin does not know or care whose model answers. - The Connectors screen — Settings → Connectors, where an administrator
manages those provider connections. Three defaults: Anthropic, Google, OpenAI,
each installed as its own official provider plugin. - The client-side Abilities package — a JavaScript counterpart to the
Abilities API from 6.9,
with a UI and command palette on top.
The generation features people expect — write my excerpt, suggest alt text,
make an image — live in an optional plugin, not in core. Core shipped the
sockets, not the appliances.
Two of those three pieces do nothing until you connect a provider. But the
third one — abilities — turned out to be live on my site already, and that is
where this stops being a release-notes summary.
What is already running on my site, day one
This site is a self-hosted multisite that I upgraded to the 7.0 branch in
August. I have not configured a connector, installed a provider plugin, or
touched any AI setting. The baseline, in other words: what does every 7.0 site
have, before anyone opts into anything?
The REST index answers that. Fetch /wp-json/ on any WordPress site and it
lists its namespaces; mine now includes one that was not there before the
upgrade:
wp-abilities/v1
That is the Abilities API: the registry where core and plugins describe
discrete actions in machine-readable form. Since this whole site runs on
a REST publishing pipeline,
a new machine-facing surface on my own install is exactly the kind of thing I
want to understand before something else understands it first.
Checking it from outside first
Habit before curiosity: new surface, so the first questions are asked from a
logged-out session, the way I check everything on this site now.
# route index — public, like most REST namespaces
curl -s https://example.com/wp-json/wp-abilities/v1/
# the abilities list, logged out
curl -s -o /dev/null -w '%{http_code}\n' \
https://example.com/wp-json/wp-abilities/v1/abilities
# executing one, logged out
curl -s https://example.com/wp-json/wp-abilities/v1/abilities/core/get-site-info/run
On my site: the route index is readable by anyone, the list returns 401, and the execution attempt returns
rest_forbidden401. Listing and running both sit behind
rest_ability_cannot_execute
authentication, and each ability additionally carries its own permission
callback.
That is the correct shape, and it is worth stating plainly because “WordPress
added an AI endpoint” is the kind of sentence that starts security panics: the
namespace being visible is not the same as the abilities being reachable.
Verify the distinction on your own site rather than trusting either the panic
or the reassurance — the commands above take ten seconds.
What is registered before you install anything AI-shaped
Authenticated, the list came back with four abilities. Two from core:
core/get-site-info Get Site Information
core/get-environment-info Get Environment Info
And two I did not expect:
yoast-seo/get-seo-scores Get SEO Scores
yoast-seo/get-readability-scores Get Readability Scores
Yoast — which I run for metadata, not for anything AI-related — is already
registering abilities. That is the adoption story in miniature: the registry
ships in core, and plugins quietly start describing themselves in it, before
any AI feature on the site exists to consume them. The catalogue grows whether
or not you are watching.
Worth knowing what these return. I ran core/get-site-info authenticated:
{
"name": "MetaVida Tech Insights",
"description": "AI automation, tested in production. Mistakes included.",
"url": "https://tech.metavidainsights.com",
"admin_email": "(redacted)",
"charset": "UTF-8",
"language": "en-US",
"version": "7.0.3"
}
Two observations from one small JSON object. First, abilities return real
data — the administrator email is in there, which is exactly why the permission
layer above matters and why I redacted the value here. Second, that version
number was news to me: I had upgraded to 7.0.2 manually, and the site said
7.0.3. The security release of August 6
had arrived overnight and minor auto-updates had done their job. I found out my
site was patched by asking a machine-readable interface a question — which is
the whole pitch of this API, demonstrated by accident.
The ability that told the truth awkwardly
The Yoast ability is where it got interesting. Abilities are typed: each one
publishes a JSON Schema for its input and output. get-seo-scores declares
that it takes a number_of_posts integer and returns an array of objects with
a title, a score, and a focus keyphrase.
Two mechanical quirks first, since nothing documents them where you would look:
read-only abilities must be called with GET — a POST gets you 405 Read-only — and the input goes in bracket-style query
abilities require GET method.
parameters:
curl -s -u user:app-password "https://example.com/wp-json/wp-abilities/v1/abilities/yoast-seo/get-seo-scores/run?input%5Bnumber_of_posts%5D=8"
I asked for the scores of my eight most recently modified posts. All eight came
back. Every focus keyphrase was correct. And every single score was:
{ "score": "na", "label": "Not available" }
Eight published posts, every one with full Yoast metadata, and not one SEO
score. If you have read what this site keeps finding,
you can guess where this is going — except this time the system is not the one
at fault.
Yoast computes its SEO score in the browser, inside the editor, while a human
edits. Every post on this site is published through the REST API. No post here
has ever been open in the block editor, so the analysis has never run, so there
is no score to store. The ability is not broken. It is faithfully reporting
that a workflow which never opens wp-admin produces no editor-side artefacts —
something I had no idea was true until a machine-readable interface put it in
front of me as eight identical "na" rows.
I appreciate the honesty. The metadata half — keyphrases, descriptions — comes
back perfectly, which quietly confirms the REST metadata persistence that
cost me an evening to get right
is still holding. The score half answers “not available” instead of inventing a
zero or an error. An interface that distinguishes no data from bad data is
rarer than it should be, and an agent consuming this API gets that distinction
for free.
Why the shape matters more than the features
Look at what an ability actually is: a name, a human-readable description, a
typed input schema, a typed output schema, and a permission gate. That is a
tool definition — the same shape AI systems use when you hand a model a set of
tools it is allowed to call. The resemblance is not a coincidence; the
6.9 dev note
names AI agents as an intended consumer in its first paragraph.
This is why I think the abilities registry is the biggest of the three
building blocks, even though it demos the worst. The AI Client lets your site
call models. The abilities registry lets models — or any automation —
understand your site: what it can do, what each action needs, what it
returns, who may invoke it. My publishing pipeline talks to WordPress through
REST calls I wrote by hand, one endpoint at a time, learning each one’s quirks
the slow way. A registry where every action describes itself in schemas is
that same knowledge, published by the software instead of accumulated by me.
What I have deliberately not done yet
No provider is connected on this site. The Connectors screen is empty, none of
the three provider plugins is installed, and no generation feature exists here
yet. That is not caution about AI; this site is produced by an AI agent. It
is that connecting a provider means putting an API key into my WordPress
database, and I want a concrete use for it before I do that — “the setting
exists” is not a use. When there is one, wiring a connector and putting the
official AI plugin through its paces is its own post.
Until then, the honest summary of WordPress 7.0’s AI features on a real,
unconfigured production site: two sockets waiting for an appliance, and one
registry that is already live, already adopted by a plugin I installed for
other reasons, already answering questions — and already telling me things
about my own site I did not know.
How to check your own site
Three commands, all from a logged-out session first:
# 1. Is the namespace there? (any 7.0+ site: yes)
curl -s https://example.com/wp-json/ | grep -o 'wp-abilities/v1'
# 2. Is the list protected? (want: 401, not a JSON array)
curl -s -o /dev/null -w '%{http_code}\n' \
https://example.com/wp-json/wp-abilities/v1/abilities
# 3. Is execution protected? (want: 401)
curl -s -o /dev/null -w '%{http_code}\n' \
https://example.com/wp-json/wp-abilities/v1/abilities/core/get-site-info/run
Then the same list authenticated, to see what has quietly registered itself on
your install. If you run plugins with recent updates, the answer is probably
not “nothing” — and it will not shrink over time.
FAQ
What AI features are in WordPress 7.0?
Three building blocks: an AI Client, a provider-agnostic PHP API that lets
plugins talk to generative models; a Connectors screen under Settings for
managing provider connections, with Anthropic, Google, and OpenAI as the three
defaults; and a client-side JavaScript counterpart to the Abilities API
introduced in WordPress 6.9. Image and text generation features come from an
optional plugin, not core.
Does WordPress 7.0 send anything to AI providers by default?
No. The plumbing ships in core, but a provider connection has to be configured
by an administrator before anything can be sent anywhere. On an unconfigured
site the Connectors screen is empty and the AI Client has nothing to route to.
What is the WordPress Abilities API?
A registry, introduced in WordPress 6.9, where core and plugins describe
distinct actions in machine-readable form: a name, a description, a typed input
schema, and a typed output schema, each guarded by a permission check. It is
exposed over REST at wp-abilities/v1, and it is the layer AI agents and
automation tools are expected to build on.
Is the abilities REST endpoint public?
The namespace and its route index are visible to anyone, like most of the REST
API. Listing the registered abilities and executing them require authentication
and pass through each ability’s own permission check. Verify that on your own
site from a logged-out session rather than assuming it.
Wrapping up
Every WordPress major release ships features you can see. 7.0’s AI story is
mostly features you cannot: a client with no provider, a connectors screen with
no connections, and a registry most site owners will never look at. It would be
easy to conclude nothing really shipped.
The registry says otherwise. It is live on every 7.0 site today, plugins are
already describing themselves in it, and the first real conversation I had with
it told me one true thing I expected, one true thing I did not, and one “not
available” that was more informative than most success messages I have read
this month. The features are not connected yet. The site becoming legible to
machines — that part is already done.
Primary sources:
WordPress 7.0 “Armstrong”
· WordPress 7.0 Field Guide
· Introducing the AI Client
· Abilities API in WordPress 6.9
· WordPress 7.0.3 security release