October 7, 2026
By
Joshua Goldfein
WordPress now has a native registry of what a site can do, and an official adapter that publishes a chosen subset of it to AI assistants. Connecting AI to a site has become a governance decision, made one ability at a time, with WordPress still deciding who may do what.
In short
The request reaches an agency in one of two forms. A client wants an assistant on the site that answers questions and books consultations, or wants their own desktop assistant to reach into the site and do work there. The first instinct is a plugin with a chat window. It ships in a week and sits beside the site like a kiosk: it answers from indexed pages and knows nothing about the forms, the roles, the editorial states, or the CRM behind the intake form.
That is the wrong layer to build on, because the question was never whether an assistant can read the site. Public pages are already readable. The question is what the site will let an assistant do, under whose authority, with what evidence left behind. WordPress 6.9 gave that question a native answer, and the official MCP Adapter now carries the answer to the assistants people use.
What an ability is
The Abilities API, added in WordPress 6.9, is a registry of what a site can do, written in a form software can read. A developer registers an ability with wp_register_ability(), describes its input and output in JSON Schema, and attaches a permission_callback that decides who may run it. With REST exposure switched on, the ability appears under wp-abilities/v1 behind ordinary WordPress authentication. WordPress 7.0 added a client-side counterpart; 7.1, the current release line, added validation filters and an invocation hook.
Core ships only a handful of abilities of its own: site, environment, and current-user information. A broader set of read abilities has been proposed and has not shipped. Everything a business cares about is an ability the site registers: return the services list, check an appointment slot, accept a consultation request.
The consultation request is the clean example. A static page tells an assistant that consultations exist, and the assistant infers that a form is somewhere. A registered ability declares the required fields, rejects what fails the schema, checks permission, hands the request to the intake system, and returns a structured result. The person on the other end has a conversation. The site receives an API call.
Where MCP comes in
The Model Context Protocol is how AI applications discover and call external systems: a host such as a desktop assistant or coding environment connects, through a client, to servers that expose tools, resources, and prompts. The Abilities API is the registry inside WordPress; MCP is the protocol an assistant speaks on the outside. The official WordPress MCP Adapter, maintained under the WordPress organization on GitHub, is the bridge: it maps registered abilities to MCP tools by default, serves read-only data as resources, and supports prompts.
Two design decisions make the adapter the governed option. Exposure is opt-in: an ability reaches the adapter’s default server only when its registration sets meta.mcp.public to true. And the ability’s permission_callback still runs when a call executes, so a connected assistant holds no more authority than the WordPress user it authenticates as. Registering a capability and publishing it to agents are separate decisions, each reviewable on its own, and WordPress stays the authority on WordPress actions. That is what keeps the AI layer from growing into a shadow application with its own permissions.
The adapter is pre-1.0. Version 0.7.0, released on October 2, 2026, is the first in the WordPress.org plugin directory and adds support for the current MCP specification, dated 2026-07-28. The durable investment is the ability layer underneath, which outlives any adapter release.
Three tiers of capability
A page inventory answers what should exist on the site. A capability inventory answers which business actions are valuable enough, and controlled well enough, to expose to software. I sort them into three tiers, and the tier decides the controls.
01
Readable
Service descriptions, FAQs, catalogs, locations, practitioner profiles, pricing guidance. Low operational risk; the first tier for almost every site.
02
Guided action
Quote request, consultation booking, support intake, availability check. Each writes something, so each needs validation, a permission design, and a log.
03
Restricted
Administrative, financial, medical, legal, or account-sensitive functions. Scoped authorization, human approval, and a reviewable audit trail, or the ability stays unregistered.
The capability map
The first artifact I want from any WordPress AI engagement is a capability map: one row per action the site performs, with its tier, who may invoke it, which system receives the result, and who owns it. The table below is an illustrative example for a professional-services site, assembled from the rows that recur; it is no client’s map.
| Ability | Tier | Who may invoke | Result goes to | Owner |
|---|---|---|---|---|
| List services and pricing | Readable | Public | Assistant | Marketing |
| Check consultation availability | Readable | Public | Assistant | Operations |
| Submit consultation request | Guided action | Public, rate-limited | CRM intake queue | Sales ops |
| Create a draft post from a brief | Guided action | Editor role | Editorial review | Content lead |
| Update published pricing | Restricted | Admin, human approval | Site and finance | Owner |
| Export customer records | Not registered | Nobody | Nowhere | Owner |
Give every ability an owner who understands the business process behind it: a quote-request ability belongs to sales operations as much as to the developer who registered it, because sales operations answers for the lead it misroutes. The last row is deliberate. A map that records what stays unregistered is more useful than one that lists only what ships.
Build the log before the first call
Decide what the log holds before anything is exposed: which ability was called, by which user or client, with which inputs, what validation occurred, what came back, and whether a downstream system changed. In WordPress 7.1 the wp_ability_invoked action fires on every invocation, including invalid input, failed permission checks, and short-circuits: the native hook for audit and tracing. The refused calls are the valuable part. A log that records only successes says nothing about what an assistant attempted and was denied.
One discipline belongs on the agent side. The July 2026 Make WordPress Core proposal on expanding core abilities states that agents consuming ability results must treat them as tool output rather than instructions to follow. Site content was written by many hands; an assistant that obeys whatever text it retrieves has handed its authority to the last person who edited a post.
A first implementation
A narrow first surface with visible business value, in this order:
-
Public read abilities
Services, FAQs, locations, contact options. Approved content, limited risk.
-
One intake ability
A consultation or quote request with strict validation and anti-spam controls.
-
A structured confirmation
Tell the assistant what happened without exposing internal data.
-
Logging with a named reviewer
Every call, including the refused ones, and a person who reads the review.
-
A human escalation path
Ambiguous, high-value, or sensitive requests go to a person.
Test the failures on purpose before production: invalid input, duplicate requests, expired authentication, an unavailable CRM. Assistants will send inputs nobody wrote a test for, and a person should be able to reconstruct what happened from the log alone.
Registering a capability and publishing it to agents are separate decisions, each reviewable on its own.
The decision that matters
Where Mercury fits
Mercury Digital’s AI WordPress Enablement work starts with an AI-readiness audit of one WordPress property. The deliverables are the capability map with owners and tiers, a permission design for each ability in the first tier, the logging specification with its review path, and a read-only feasibility check against the MCP Adapter before any write ability is considered. If your site carries lead flow, scheduling, commerce, or support that matters to the business, that map is the first useful artifact.
Verified October 5, 2026: WordPress 7.1.2 is current and the MCP Adapter is at 0.7.0, pre-1.0. The architecture described here is stable; version-level details will keep moving.
