Exposure and Ownership

Exposure#

An ability can be reached through the REST API and through MCP. Ability Auditor works out the effective value for each channel:

Channel	Effective value
REST	meta.show_in_rest, else meta.public, else false
MCP	meta.mcp.public, else meta.public, else false

• An explicit false always wins over public: true.
• Before WordPress 7.1, meta.public is ignored because core did not support it yet.
• Each value shows where it comes from: explicit, from public, default, or set by core. The plugin records every ability’s raw registration arguments as abilities register, before core merges public into show_in_rest; that is the only way to tell explicit from inherited.
• MCP exposure is computed by the plugin. Core never reads meta.mcp.public; it is a convention that MCP adapters follow.

If some abilities registered before Ability Auditor loaded, the Report tab shows a notice and their exposure is reported as set by core rather than explicit or inherited.

Ownership#

The auditor uses PHP Reflection to find where each ability’s code is defined and maps that file to an installed component. Nothing is called.

1. Evidence, strongest first: the custom ability_class, then the execute callback, then the permission callback.
2. Mapping: the file is matched to a plugin folder, a single-file plugin, an mu-plugin, a theme or core. Symlinked plugins are handled.
3. Core functions do not count. A named core function such as __return_true or is_user_logged_in as the permission callback proves nothing about who registered the ability. Core only owns an ability through a closure or class defined in core.
4. Unknown locations give an Unknown owner that still shows the source file.
5. Name fallback. With no file evidence at all, the namespace is matched against plugin folders and text domains. The core namespace is never trusted on its own.
6. Spoofing warning. An ability named core/... that is not defined in core is flagged.