WordPress 7.1: one flag decides what agents can call

WordPress 7.1 ships today, on the last day of WordCamp US in Phoenix — our home field. The headline features are editor work: responsive block styles, pseudo-state controls, Notes with suggestion mode. The line that actually changes your risk surface is one boolean in the Abilities API: a unified public flag that decides whether an ability is visible to the REST API, MCP adapters, and AI agents at all.

What actually happened

The Abilities API is how WordPress registers callable capabilities — "publish this post," "look up this order" — so external clients can discover and invoke them. Until 7.1, an ability author had to declare exposure separately for every channel. The dev note on the unified public flag is blunt about why that broke: repeating the same intent through several channel-specific flags becomes difficult to maintain.

The mechanics, exactly:

• Every registered ability now resolves a boolean public property in its metadata.
• The default is false when you do not supply it. Nothing becomes newly reachable by upgrading.
• Channel flags still win. Resolution is $show_in_rest = $meta['show_in_rest'] ?? $meta['public'] ?? false; — so an ability can be public => true and show_in_rest => false at the same time.
• Existing show_in_rest registrations keep working. No function signatures changed.
• The MCP Adapter will respect the unified flag starting with its next release.

The dev note also states the part people will skip: exposure is not authorization. public controls discoverability only. Abilities still need a real permission_callback.

Further Abilities API improvements landed in the same release — custom validation hooks, an invocation lifecycle action, selective field responses, and core/get-user-info now exposed through REST.

Why it matters for your business

We build WordPress and WooCommerce systems for operators, so here is the read that matters after you click update.

One flag is a real improvement and a real single point of failure. Before, flipping an ability open to agents took several deliberate edits. Now it takes one. That is better ergonomics and a shorter distance between "a plugin author wanted a demo to work" and "a model can call your order lookup."

Audit the plugins, not core. Core defaults to closed. Third-party plugins racing to look agent-ready are where public => true will show up without a matching permission check. Grep your plugin directory for ability registrations and read every permission_callback you find. An ability with no capability check is an unauthenticated endpoint with better marketing.

core/get-user-info over REST is a decision, not a default. User data reachable through a documented, agent-discoverable channel changes what an exposed API key is worth. Know which of your abilities touch customer records before something else discovers them for you.

Test the invocation lifecycle before you need it. The new lifecycle action is where you put logging. If an agent calls your site next quarter, the question will be what did it call and when — and the only good answer is one you instrumented on purpose.

Sources: Make WordPress Core — unified public flag, Make WordPress Core — Abilities API improvements in 7.1, Roadmap to 7.1.