WordPress 7.1 Abilities API: Your Site Is Now AI-Agent-Ready

WordPress 7.1, released nine days ago, introduces five improvements to the Abilities API, making WordPress sites AI-agent-ready by standardizing how plugins declare and expose capabilities to external systems like AI agents via the Model Context Protocol (MCP). Key changes include a single meta.public flag for external exposure, lifecycle hooks around every invocation, filterable discovery, auto-generated MCP-compatible schemas, and a consistent REST collection endpoint. The update builds on infrastructure from WordPress 6.9 and is aimed at developers building AI integrations.

WordPress 7.1 shipped nine days ago. Editor coverage dominated the announcements: icon system updates, iframe improvements, admin screen changes. Meanwhile, the release that actually matters for developers working with AI integrations landed quietly in the changelog. The Abilities API — infrastructure since WordPress 6.9 — is now a toolkit. If you build plugins or connect AI agents to client sites, this is the 7.1 story worth reading. What the Abilities API Does The Abilities API gives plugins a standardized way to declare what they can do. Instead of building ad-hoc REST endpoints or custom integrations, a plugin registers typed, permissioned actions — abilities — that describe their inputs and outputs in JSON Schema. External systems, including AI agents, can discover and invoke these abilities through the Model Context Protocol MCP https://make.wordpress.org/core/2026/08/05/wordpress-7-1-field-guide/ . Before 6.9, connecting an AI agent to WordPress meant building custom glue. Now it means registering an ability and flipping a flag. What Changed in the WordPress 7.1 Abilities API WordPress 7.1 adds five concrete improvements to the Abilities API, none of which are in any headline. 1. One Flag to Rule External Exposure The biggest change is the simplest. A single meta.public boolean now governs whether an ability is visible to external clients — MCP adapters, REST consumers, AI agents. Previously, making an ability externally accessible required setting scattered channel-specific flags. Now: set meta.public to true and your ability appears in MCP discovery, the REST collection endpoint, and any AI client querying the site. One flag. One decision point. One place to audit. There is a cost to acknowledge: every public ability is network-accessible. Core provides no rate limiting. Auth is the plugin’s job. Flipping that flag carelessly is a security decision, not just a feature toggle. 2. Lifecycle Hooks Around Every Invocation Ability callbacks used to be black boxes. 7.1 wraps every invocation https://make.wordpress.org/core/2026/07/29/new-execution-lifecycle-filters-for-the-abilities-api-in-wordpress-7-1/ with a four-stage lifecycle: input normalisation, validation, before-callback, and after-callback filters. You can now intercept AI agent calls at any stage — enforce custom authorization policies, transform inputs before they hit your callback, short-circuit dangerous invocations, or post-process results. A subscription plugin can reject calls from unauthenticated MCP clients before the callback runs. An audit plugin can log every external invocation without touching the registered ability. This is the change that makes abilities policy-enforceable. 3. Filterable Discovery wp get abilities now accepts a $args array with namespace, category, and metadata filters. AND logic: an ability must match all criteria to appear. The REST collection endpoint mirrors these as query parameters: GET /wp-json/wp-abilities/v1/abilities?namespace=woocommerce&meta public =true AI agents can now request exactly what they need instead of fetching the entire registry and filtering client-side. This is how real MCP tool discovery is supposed to work. 4. Auto-Generated MCP-Compatible Schemas The ability input/output schemas are now automatically prepared in a format MCP clients can consume without transformation. Previously, the MCP Adapter had to do schema translation work. Now abilities emit client-compatible JSON Schema directly. Less friction in the bridge, fewer edge cases at the protocol boundary. 5. Consistent REST Collection The REST collection endpoint now delegates directly to wp get abilities and exposes its filtering arguments as query parameters. The endpoint and the PHP API are consistent. Querying via REST or PHP gives the same result set with the same filter semantics. Registering Your First Public Ability Here is the minimal working pattern for a public ability in 7.1: add action 'wp abilities api init', function { wp register ability 'my-plugin/get-post-count', 'label' = 'Get Published Post Count', 'description' = 'Returns the number of published posts on this site', 'category' = 'content', 'meta' = 'public' = true , 'input schema' = 'type' = 'object', 'properties' = , , 'execute callback' = function $input { return 'count' = wp count posts - publish ; }, ; } ; Install the WordPress MCP Adapter https://github.com/WordPress/mcp-adapter , register the ability above, and any MCP client — Claude Code, Cursor, GitHub Copilot Agent — can discover and invoke it. The adapter converts public abilities into MCP tools automatically. Your site is now an MCP server. ByteIota covered the browser side of MCP earlier this week in WebMCP in Chrome 149 https://byteiota.com/webmcp-chrome-149-ai-agent-ready/ — this is the same protocol, now natively in your WordPress stack. The Ecosystem Reality The infrastructure is solid. The ecosystem is not there yet. The Abilities Directory https://easymcpai.com/abilities-directory lists 80+ plugins with registered abilities. WooCommerce and Jetpack are both on board. But most plugins are not. Major tracking plugins — the kind you probably have on every client site — have not adopted the API. The AI agent you connect will only see what’s registered. If your critical plugin hasn’t shipped ability support, you’re building on a partial picture. This is not WordPress’s failure. The pattern is correct. Plugin authors haven’t caught up yet. Expect the gap to narrow over the next two release cycles as 7.1 becomes the adoption pressure point. What to Do Now Three concrete steps if you’re building AI integrations on WordPress: Update to 7.1. The lifecycle hooks and public flag are the foundation. You need them before anything else works. Audit your stack. Check the Abilities Directory https://easymcpai.com/abilities-directory against every plugin on your sites. Know the gaps before your AI agent does. Register your own abilities. If you maintain a plugin, this is the cycle to add ability registration. The MCP Adapter documentation https://developer.wordpress.org/news/2026/02/from-abilities-to-ai-agents-introducing-the-wordpress-mcp-adapter/ covers the full bridge from ability to AI tool. WordPress has had an AI strategy since 6.9. 7.1 is the first release where that strategy has enough API surface to build something real. The editor updates are fine. The Abilities API is the story.