Since WordPress 6.9, “adding AI to WordPress” stopped meaning “install a plugin that calls an API” and started meaning something more structural: WordPress core now has a formal way to describe what a site can do, and a growing set of official tools for letting AI systems discover and use those capabilities safely. This lesson gives you the map before you start building on any one piece of it.
No prior AI or MCP knowledge required. You should be comfortable with basic WordPress admin concepts (plugins, roles) and have read access to a terminal, you won’t run complex commands yet, just confirm your environment in this lesson.
The problem: every AI plugin used to invent its own interface
Before WordPress 6.9, if you wanted an AI assistant to create a post, update a product, or read your site’s settings, that capability existed only inside whatever plugin built it, with whatever authentication, permission model, and data shape that plugin’s author chose. A chatbot plugin’s “create a post” feature and a page-builder’s AI assistant’s “create a post” feature were two completely different, incompatible pieces of code doing conceptually the same thing.
The WordPress AI Team’s response was to build a shared foundation: a standard way for any plugin, or WordPress core itself, to register a discrete unit of functionality, called an ability, with a name, a description, a defined input and output shape, and a permission check. Once an ability exists in that standard shape, any AI tool that knows how to read it can use it, without a plugin-specific integration.
The four pieces, and how they fit together
| Piece | What it is | Ships as |
|---|---|---|
| Abilities API | Core WordPress functions for registering a capability (an “ability”) with a schema and a permission check. | WordPress core, since 6.9 |
| Model Context Protocol (MCP) | An open, WordPress-agnostic standard (from Anthropic) that defines how an AI client talks to a server exposing tools, resources, and prompts. | Protocol spec, not WordPress-specific |
| MCP Adapter | The official WordPress plugin that takes your registered abilities and serves them to MCP clients over HTTP or STDIO. | Separate plugin, github.com/WordPress/mcp-adapter |
| PHP AI Client SDK | A provider-agnostic PHP library for calling out to an LLM (Claude, GPT, Gemini) from your own WordPress code. | Core entry point (wp_ai_client_prompt()) since WordPress 7.0, standalone package for use outside WordPress too |
Notice that only two of these four things are really “WordPress AI features” in the traditional sense. The Abilities API is a registration system, it doesn’t talk to AI at all by itself. MCP is a protocol that exists independently of WordPress. The MCP Adapter is the bridge that connects your abilities to that protocol. The PHP AI Client SDK is a completely separate concern, it’s for when your own PHP code wants to ask an AI model something, not for exposing your site to an external agent.
Two directions of AI traffic
This is the single most useful mental model in this whole course: there are two opposite directions AI-related data can flow through your site, and each uses a different piece of the stack.
AI calling WordPress (agents-in): an external AI client, Claude Desktop, Cursor, ChatGPT, connects to your site and asks it to do something, create a draft, look up an order, summarize recent comments. This path is: your registered abilities → the MCP Adapter → MCP → the AI client. Course 2 and Course 3 in this track live here.
WordPress calling AI (agents-out): your own plugin code needs an AI model to do something, generate a product description, classify a support ticket, summarize a long page. This path is: your PHP code → the PHP AI Client SDK → an LLM provider (Claude, GPT, or Gemini) → back into your code. Course 5 lives here.
Plenty of real features use both directions at once, an agent asks your site to “draft a reply to this comment” (agents-in), and your site’s own code uses the AI Client SDK to actually generate that reply (agents-out) before handing it back. Course 5’s final lesson covers combining the two directly.
Test it: confirm what your environment already supports
You don’t need anything installed yet to check this. If you have terminal access to a WordPress install (local or otherwise) with WP-CLI available, run:
# Check WordPress core version
wp core version
# Check whether the Abilities API is present in this version
wp eval 'var_dump( function_exists( "wp_register_ability" ) );'If your site is on WordPress 6.9 or later, the second command should print bool(true).
If it prints bool(false), your install predates the Abilities API landing in core,
which is exactly what the next lesson’s environment setup fixes.
Two things trip people up immediately: first, assuming the Abilities API and MCP are
the same thing, they’re not, the Abilities API works fine with zero AI clients
connected, it’s just a registration system. Second, referencing the older
Automattic/wordpress-mcp plugin, that project is being deprecated in favor of the
official WordPress/mcp-adapter this course uses, don’t follow tutorials built on it.
Recap
WordPress’s AI stack is four distinct pieces solving four distinct problems: the Abilities API registers what your site can do, MCP is the open protocol that describes how an AI client talks to a server, the MCP Adapter is WordPress’s official bridge between the two, and the PHP AI Client SDK is a separate tool for when your own code needs to call an AI model directly. Keep the “AI calling WordPress” versus “WordPress calling AI” distinction in mind, it will make every later lesson easier to place.