Unifiied Abilities exposure controls

[artpi]

After implementing a few consumers of abilities, it seems that we need a unified effort to control what abilities are available where.

In the simplest implementation:

• Plugin can declare a "Surface" for abilities (wp_abilities_register_consumer or something like this)
• User can choose which abilities are available where

Why?

Abilities will come from plugins and we have no control over their quality and behavior - some of them will be splendid, some of them - not so much.
We need a way for the user to say "i want this, this and this abilities to available in Claude via MCP, but i want these avialable in my AI agent available on this site"

If we don't do this centrally, I predict every plugin with a "surface" shipping its own version and we'll have a mess

Rough idea

• You may use abilities as curently - then you have access to entire catalog
• You also may register a "surface" for your use case for the abilities
• When you do, a UI automatically appears in WP-Admin so you can decide which abilities are available on that surface
• You can query abilities API via surface
• Every MCP server automatically becomes a surface

It is kind of related to #348

CC @gziolo @jorgefilipecosta

[gziolo]

Related: I opened Abilities API: Add filtering support to wp_get_abilities() ticket to add filtering support to wp_get_abilities(). The Observed need section documents exactly the fragmentation you're describing, presenting the MCP adapter, WooCommerce, and WebMCP adapter, all of which have built their own ad-hoc filtering because the API doesn't offer it natively.

The "surface" concept here maps well to the filtering + hooks pipeline proposed in that ticket. A registered surface could translate into $args (category, namespace, meta) plus ecosystem-scoped hooks that enforce per-surface visibility. That way wp_get_abilities() becomes the single query point regardless of consumer, and surface-level controls layer on top via filters rather than each plugin reimplementing the selection logic.

[gziolo]

A first building block for this shipped in WordPress 7.1: wp_get_abilities() now supports unified filtering — declarative args (category, namespace, nested meta with strict comparison), per-call item_include_callback / result_callback, and global wp_get_abilities_item_include / wp_get_abilities_result filters, all running in a single registry pass. The REST collection endpoint exposes the same filters as query params, with boolean coercion for the built-in readonly / destructive / idempotent annotations.

Dev note: https://make.wordpress.org/core/2026/08/05/filtering-registered-abilities-with-wp_get_abilities-in-wordpress-7-1/

In practice this means a surface no longer needs its own array_filter(). It can be a filtered query, with wp_get_abilities_item_include as the central hook. As a next step, we could consider a new meta annotation declaring the user capabilities (and/or roles) an ability requires, so a surface only exposes abilities matching the current user's permissions.

[whyisjake]

Today's AI team call hit this same problem from the workspace side

The call concluded that we can't assume every registered ability should be callable by a general-purpose assistant. An ability has to declare that it's usable there. That's this issue's problem arriving from a second direction, which argues for settling it here rather than in each surface.

Two things worth pinning down.

First, there's already precedent and already divergence. meta carries show_in_rest and mcp.public today: two consumers, two separately-invented exposure mechanisms. A third surface inventing ai_workspace.public is the outcome this issue predicts, so the AI Workspace shouldn't ship its own flag. It should be the first consumer of whatever gets settled here.

Second, the default decides how much of this is a security control. Ability annotations (readonly, destructive, idempotent) default to null rather than false, and they're the author's claim about their own code, not something WordPress enforces. Only three of the six ability files in this plugin set mcp meta at all. An opt-out default would publish every third-party ability to a conversational surface the moment it registers, so unannotated has to mean not admitted.

What would satisfy the workspace: an ability declares which surfaces it's eligible for, the site owner sees the resulting list and can change it, and nothing reaches a general assistant without both.

[gziolo]

There is now a unified public exposure flag for Abilities in WordPress 7.1. It defaults to false. When meta.show_in_rest is not defined, then it inherits the value from meta.public. The same strategy applies to meta.mcp.public.

[whyisjake]

I was wrong, and core had already solved it.

My comment above described show_in_rest and mcp.public as two separately-invented mechanisms and argued for a central one. meta.public had been that central one for a month by the time I wrote it. I should have looked for a dev note before making the argument.

The narrower half survives: the AI Workspace should not invent ai_workspace.public. That is a stronger claim now rather than a weaker one, since there is a documented precedence to follow instead of a gap to fill. #1014 resolves meta['ai-workspace']['public'] ?? meta['public'] ?? false, so an ability marked public is eligible for the assistant without naming the surface.

Two things surfaced while implementing against it.

The inheritance is not applied uniformly. Core resolves show_in_rest at registration and writes the answer back into meta (class-wp-ability.php:370), so reading that key gives the resolved value. Nothing resolves mcp.public. I read both keys directly and shipped an Explorer column that reported an ability as absent from MCP when meta.public had put it there. Every consumer hand-writing the same ?? meta.public ?? fallback is a smaller version of what this issue is about, so it may be worth resolving mcp.public in core alongside show_in_rest.

The other one changed a user-facing string. Because core seeds meta.public on every ability and validates it as a boolean, "the author declared nothing" stopped being a reachable state. I had two exclusion reasons, "not declared by its author" and "declaration malformed", and both became untrue: an ability with no opinion is eligible-false by core's default, not undeclared. They collapsed into one, "not public, and has not opted in". Any consumer reporting why an ability is unavailable will hit the same thing.

One question I could not settle from the dev note. Inheriting means every public ability is eligible for a surface reachable by instructions embedded in content the model retrieves, which is a wider default than the opt-in this project's AI team call settled on. The dev note allows a channel to keep its own default, so declining to inherit would be within the pattern. We chose to inherit and lean on a separate effect-class check (readonly: true, destructive: false, open_world: false, all three explicit) so a public ability that writes or reaches outside the site is still refused. That works, but it does mean "public" carries a different weight for a REST endpoint a developer calls than for a tool a model can be talked into calling. Worth knowing whether that was the intent.

Admission in #1014 is off by default until the channel name settles here, so none of this is load-bearing yet.