WordPress 6.9 “Gene” arrived on December 2, 2025, and WordPress 7.0 “Armstrong” followed on May 20, 2026. Between those two releases, the project quietly added the pieces that let an AI agent read a WordPress site and act on it. Most of the coverage rolled them into one headline, “WordPress is now agentic,” as if a single switch had been flipped. There is no single switch. There are three distinct building blocks, each with its own job, and one of them is not even in core. Let’s take them one brick at a time, together.
What makes a WordPress site “agentic”?
For an AI agent to operate a website, three things have to be true. The site has to declare what it can do in a form a machine can read. Something has to let the site’s code talk to an AI provider. And something has to let an outside agent discover those capabilities and call them safely. WordPress now has one piece for each: the Abilities API, the AI Client, and the MCP Adapter. WordPress becomes agentic not through a single feature but through three layers that each do one job: declare, talk, and drive. They all grew out of the same effort, the AI Building Blocks for WordPress initiative, which is why they fit together so cleanly.
Brick one: the Abilities API, or what your site can do
The first brick is the oldest. The Abilities API was merged into WordPress core in 6.9, released on December 2, 2025. In the words of the dev note that introduced it, it is “a new foundational system that enables plugins, themes, and WordPress core to register and expose their capabilities in a standardized, machine-readable format.” Each capability is called an ability, defined as a self-contained unit of functionality with set inputs, outputs, permissions, and execution logic.
Think of it as a catalogue the site publishes about itself. “Create a draft post,” “fetch the last ten orders,” “run a diagnostics check”: each one is registered with a typed schema and a permission rule. The Abilities API does not call any AI; it simply describes, in a predictable way, what the site is allowed to do. That description is the foundation everything else stands on, because an agent cannot act on what it cannot read.
Brick two: the AI Client, or how your site talks to AI providers
The second brick shipped with 7.0. The AI Client is, in the words of its own dev note, “a provider-agnostic PHP API that lets plugins send prompts to AI models and receive results through a consistent interface.” A plugin reaches it through a single entry point, the wp_ai_client_prompt() function, and WordPress routes the request to whichever provider the site owner has configured.
The important word is provider-agnostic. The same plugin code can reach OpenAI, Anthropic, or Google without being rewritten for each one, because the AI Client handles the routing. WordPress core itself calls no model and writes no content on its own; the AI Client only offers a standard way for code to ask, when code chooses to ask. We go deeper into that reframe, and why upgrading to 7.0 does not turn your site into an AI writer, in our piece on what the AI Client actually changes.
Brick three: the MCP Adapter, or letting an agent drive
The third brick is the one that turns the first two into something an external agent can use, and it is also the one to be precise about. The MCP Adapter is not in core. It is an official package in the AI Building Blocks for WordPress initiative, installed as a separate plugin from the releases page of its GitHub repository, and it requires WordPress 6.9 or later because it depends on the Abilities API.
Its job, stated plainly in the dev note that introduced it, is “to adapt Abilities registered by the Abilities API into the primitives supported by the Model Context Protocol (MCP) so that AI tools (like Claude Desktop, Claude Code, Cursor, and VS Code) discover and call WordPress Abilities directly.” So an agent in your editor can list what the site offers and invoke one of those abilities over a standard protocol. The MCP Adapter is the bridge that lets an outside AI agent discover your declared abilities and call them, and right now it is a feature plugin rather than a core component.
Why the official adapter is not a “run any code” plugin
This is the distinction worth keeping, because the wording around MCP and WordPress blurs two very different things. Several third-party MCP plugins expose broad hooks, some going as far as a raw PHP or WP-CLI execution endpoint, which hands an agent the keys to run almost anything. THE official MCP Adapter does the opposite. It exposes only the abilities registered through the Abilities API, each with its typed schema and its permission callback, and nothing else.
The official adapter surfaces bounded, declared capabilities you control, not arbitrary code execution, and that boundary is the whole point of building it on the Abilities API. If you have only ever seen MCP described through a plugin that runs shell commands, the core path is a deliberately narrower and safer design. The agent can do what you have declared, with the permissions you have set, and no more.
Our take
The agentic story is real, but it is an architecture, not a magic feature you switch on. What matters for a practitioner is that the building blocks are deliberately layered and, in the official path, deliberately bounded. Two of the three bricks are in core today, the third is an opt-in plugin, and none of them does anything until you register an ability and decide who may call it. That is reassuring rather than dramatic, which is how we prefer our infrastructure.
So here is a calm way to approach it. If you are only curious, read the bricks as a map and wait: nothing is exposed by default. If you want to experiment, install the MCP Adapter on a staging site, register one narrow ability, and confirm exactly which agent and which user can call it before you go further. And if you maintain client sites, audit any third-party MCP plugin for a raw code-execution endpoint and prefer the bounded official path. Whatever your case, keep it on staging first, and if you have not moved up yet, our cautious checklist for upgrading to WordPress 7.0 covers the rest. The bricks are in place now; what you let an agent do with them stays your decision.
