WordPress 7.1 ships today, 19 August 2026, timed to land on the closing day of WordCamp US in Phoenix. Most of the release coverage will focus on the visible wins: responsive block styles in theme.json, pseudo-state styling for buttons and navigation links, an SVG icon registration API, and an admin design system built on semantic CSS custom properties. All useful. None of it is the story.
The story is the Abilities API. It arrived in 6.9 as bare infrastructure, something you could technically build against but had little reason to. In 7.1 it picks up a filterable execution lifecycle, custom validation, a shared discovery pipeline, JSON Schema support, and a standardised flag controlling which abilities are exposed to external clients. That combination is the difference between a foundation and a toolkit. WordPress has quietly given itself a machine-readable description of what it can do, and that changes what the platform is for.
TL;DR
- WordPress 7.1 releases 19 August 2026 during WordCamp US Phoenix, with the Abilities API as the most strategically significant change in the release.
- The Abilities API is a registry, not an endpoint. Plugins and core register named capabilities via
wp_register_ability()with structured schemas, and any consumer can discover them through a shared pipeline rather than reverse-engineering custom REST routes. - It is the substrate for the WordPress MCP Adapter, which maps registered abilities onto Model Context Protocol tools and resources so AI agents can discover and execute site functionality without bespoke integration work.
- React 19 slipped again. WordPress core stays on React 18.3 with React 19 still experimental in Gutenberg, so hold any migration plans that assumed otherwise.
- The public exposure flag is a security control, not a convenience toggle. Every ability you expose becomes an action an external agent can invoke, which makes permission callbacks and input validation load-bearing in a way they were not before.
What actually shipped
The mechanics are straightforward. You register an ability inside a function hooked to wp_abilities_api_init, giving it a namespaced name in plugin-slug/ability-name format, a description, input and output schemas, an execute callback, and a permission callback. Consumers query the registry through wp_get_abilities().
add_action( 'wp_abilities_api_init', function () {
wp_register_ability( 'acme-crm/create-lead', array(
'label' => __( 'Create a CRM lead', 'acme-crm' ),
'description' => __( 'Creates a lead record from a name and email address.', 'acme-crm' ),
'input_schema' => array( /* JSON Schema */ ),
'output_schema' => array( /* JSON Schema */ ),
'execute_callback' => 'acme_crm_create_lead',
'permission_callback' => function () {
return current_user_can( 'edit_posts' );
},
) );
} );What 7.1 adds on top is the part that matters operationally. The execution lifecycle is filterable, so you can hook into ability processing at multiple stages for logging, rate limiting, or policy enforcement without wrapping every callback yourself. Validation rules can be defined per ability rather than hand-rolled inside each execute callback. And the discovery pipeline means one registration is visible to every consumer, instead of each integration maintaining its own list of what your site can do.
Why a registry beats another REST endpoint
The obvious objection is that WordPress already has a REST API, and anything you can do with an ability you could do with a custom route. True, and beside the point.
A REST route tells a consumer where to send a request. It does not tell them the route exists, what it means, when calling it is appropriate, or what shape the response takes. That knowledge lives in documentation, in tribal memory, and in whatever integration code someone wrote eighteen months ago. Every new consumer pays the discovery cost again.
An ability is self-describing. The name, description, and JSON Schema travel with the capability itself. That is a small change for a human developer reading docs and an enormous one for a non-human consumer that has to work out what is available at runtime. This is the same architectural shift we wrote about in agent-native software design: the interfaces that survive the next few years will be the ones that explain themselves.
The MCP connection
The Abilities API only makes full sense alongside the WordPress MCP Adapter, which arrived earlier this year. The adapter takes abilities registered through the API and maps them onto Model Context Protocol primitives, exposing executable abilities as MCP tools and readable data as MCP resources.
The practical consequence is that you register a capability once and it becomes available to any MCP-speaking client: Claude, ChatGPT, Cursor, an internal orchestration layer, a customer support agent. You are not writing a Claude integration and then a separate ChatGPT integration. You are describing your site’s capabilities once and letting the protocol handle distribution.
For anyone running WordPress as an application platform rather than a brochure site, this is genuinely significant. Your editorial workflow, your booking system, your product catalogue, your custom post types: all of it becomes addressable by agents without a bespoke API project for each consumer.
The security question nobody is answering loudly enough
Here is where we would urge caution. The public exposure flag exists because exposing an ability to external clients is a meaningfully different act from registering it for internal use, and the API is right to make that distinction explicit. But an explicit flag only helps if teams treat it as a security decision rather than a checkbox to tick during integration testing.
Three things deserve real scrutiny before you expose anything:
Permission callbacks become the perimeter. In a traditional admin flow, a capability check is one layer among several, backed by the fact that a human had to navigate to a screen and click something. An agent invoking an ability has none of that friction. The permission callback is doing the entire job.
Input validation is now adversarial. Structured schemas help, but a schema validates shape, not intent. If an ability accepts free text that eventually reaches a database query, a file path, or an outbound request, treat that input as attacker-controlled. Indirect prompt injection has already moved from theory to observed attack in production agent systems, and a comment field on your own site is exactly the sort of untrusted surface that ends up in an agent’s context window.
Blast radius needs bounding. An ability that creates a draft post is not the same risk as one that publishes, deletes, or triggers a payment. Start with read and draft operations, add write operations deliberately, and log every execution with enough context to reconstruct what happened.
A sensible adoption path
For most teams the correct move is not to rush abilities into production this week. It is to spend the next quarter doing three things in order.
First, audit what your site actually does. Most WordPress installations that have accumulated a decade of plugins and custom code have no current inventory of their own capabilities. You cannot register abilities meaningfully without one, and the audit has value regardless of whether you ever ship an ability.
Second, register abilities internally with the public exposure flag off. Use them from your own admin tooling and automation first. This gets the schemas right, exercises the permission callbacks, and surfaces the awkward cases while the only consumer is you.
Third, expose selectively, starting with read-only abilities, behind authentication, with execution logging in place from day one.
Separately, and unrelated to abilities: the post editor is now always iframed in 7.1. If you have custom editor code reaching into the canvas document directly, it will need adjusting. That one will bite people.
The strategic read
WordPress powers a large share of the web and has spent much of the last five years defending that position against headless architectures and JavaScript meta-frameworks. The Abilities API is a smarter response than another Gutenberg iteration, because it competes on a dimension where an established CMS has a structural advantage: it already contains the content, the workflows, and the business logic that agents need to act on.
A greenfield application has to build agent-addressable capabilities from nothing. A WordPress site has to describe what it already does. That is a much shorter distance to cover, and 7.1 is the release that makes covering it practical.
Whether the ecosystem takes the opportunity is a different question. Plugin authors have to register abilities, define honest schemas, and write permission callbacks that hold up under automated invocation. That is real work with no immediate user-visible payoff, which historically is not where the WordPress plugin economy moves fastest. Our expectation is that adoption will be slow for two release cycles and then sudden, once one or two major plugins make agent-addressability a competitive feature and everyone else has to follow.
The teams that benefit will be the ones that did the capability audit early.
Building WordPress as an application platform rather than a website? REPTILEHAUS works with entrepreneurs, product teams, and agencies on exactly this kind of architecture: custom WordPress development, AI agent integration, MCP tooling, and the DevOps to run it safely. If you are weighing up what the Abilities API means for your stack, get in touch.
📷 Photo by Albert Stoynov on Unsplash
