WordPress 7.1 introduces a new public metadata flag for abilities. The flag provides a single, high-level way to indicate that an ability is intended to be available to external clients such as the REST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/, MCP adapters, and AI agents.

Table of contents:

1. Registering a public ability
2. How exposure defaults are resolved
3. What problem does this change fix?
4. Using public in other integrations
5. Exposure is not authorisation
6. Changes to resolved metadata
7. Backward compatibility
   1. Existing Core abilities
8. When to use each flag

Previously, ability authors had to express that intent separately for every exposure channel. For example, an ability exposed through the REST API needed to set show_in_rest directly:

'meta' => array(
	'show_in_rest' => true,
),

As the Abilities API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. gains more client integrations, repeating the same intent through several channel-specific flags becomes difficult to maintain. The new public flag establishes a common default while preserving granular control for each channel.

An ability intended for client exposure can now set meta.public when it is registered:

function my_plugin_register_abilities(): void {
	wp_register_ability(
		'my-plugin/export-users',
		array(
			'label'               => __( 'Export users', 'my-plugin' ),
			'description'         => __( 'Exports user data as CSV.', 'my-plugin' ),
			'category'            => 'data-export',
			'execute_callback'    => 'my_plugin_export_users',
			'permission_callback' => function (): bool {
				return current_user_can( 'export' );
			},
			'meta'                => array(
				'public' => true,
			),
		)
	);
}

add_action( 'wp_abilities_api_init', 'my_plugin_register_abilities' );

For the REST API, setting public to true makes show_in_rest default to true. The ability can therefore be discovered and invoked through the REST abilities endpoints, subject to its permission callback.

Channel-specific settings take precedence over the general public setting. The effective REST exposure value is resolved as follows:

$show_in_rest = $meta['show_in_rest'] ?? $meta['public'] ?? false;

For example, an ability that is generally public but must not be exposed through REST can use:

'meta' => array(
	'public'       => true,
	'show_in_rest' => false,
),

The explicit show_in_rest value wins over public.

Conversely, an ability that is not generally public can still opt into REST specifically:

'meta' => array(
	'public'       => false,
	'show_in_rest' => true,
),

The resolution uses null-coalescing semantics so an explicit false is preserved. It is not treated as a missing value.

A null value is treated as unset and falls back to the next value in the chain.

In practical terms:

This precedence allows for a broad exposure default while opting in or out of individual channels.

Ability metadata already contained channel-specific exposure settings such as show_in_rest. As support for MCP, AI agents, and other clients develops, requiring ability authors to configure each channel independently would duplicate the same policy across multiple properties:

'meta' => array(
	'show_in_rest' => true,
	'mcp'          => array(
		'public' => true,
	),
	// Additional flags for future clients.
),

This also makes it difficult for a newly introduced channel to determine whether an existing ability was intended for external use.

The public flag fixes this by recording the ability author’s general exposure intent in one stable location:

'meta' => array(
	'public' => true,
),

Individual integrations can use that value as their default while retaining a more specific channel-level override.

REST is the first built-in consumer of this behaviour. Other integrations can adopt the same default without adding channel-specific logic to WordPress Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

The resolved public value remains available in the ability’s metadata. Client integrations can inspect this value when determining whether an ability should be exposed.

The WordPress MCP Adapter will respect the unified public flag starting with its next release. WP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/ does not apply this exposure check because its ability-listing functionality returns all registered abilities.

Other integrations should generally resolve exposure when abilities are selected for that integration:

function my_plugin_is_ability_exposed(
	WP_Ability $ability,
	string $channel
): bool {
	$meta = $ability->get_meta();

	return $meta[ $channel ]['public'] ?? $meta['public'] ?? false;
}

Integrations that need to derive their own channel-specific metadata during registration can use the existing wp_register_ability_args filter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.:

add_filter(
	'wp_register_ability_args',
	function ( array $args, string $name ): array {
		if (
			! isset( $args['meta']['my_client']['public'] )
			&& isset( $args['meta']['public'] )
		) {
			$args['meta']['my_client']['public'] =
				(bool) $args['meta']['public'];
		}

		return $args;
	},
	10,
	2
);

An integration should follow the same precedence rule as REST:

1. Use an explicit channel-specific value when present.
2. Otherwise, inherit public.
3. Otherwise, use the channel’s built-in default.

Integrations should not overwrite an explicit channel opt-out merely because public is true.

The public flag controls discoverability and client exposure. It does not make an ability executable without authorisation, and it does not replace the ability’s permission_callback.

Every ability must continue to implement an appropriate permission check:

'permission_callback' => function (): bool {
	return current_user_can( 'manage_options' );
},

An ability with public => true may be visible through a client while still requiring authentication and specific WordPress capabilities A capability is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on their role. For example, users who have the Author role usually have permission to edit their own posts (the “edit_posts” capability), but not permission to edit other users’ posts (the “edit_others_posts” capability). to execute.

Developers should not treat public, show_in_rest, or any other exposure flag as a security boundary. Authorisation must be enforced by the ability itself.

In WordPress 7.1, the resolved metadata for every ability includes a boolean public property. It defaults to false when it is not supplied during registration.

For example:

$ability = wp_get_ability( 'my-plugin/export-users' );
$meta    = $ability->get_meta();

$is_public = $meta['public']; // Always a boolean in WordPress 7.1.

This gives consumers a consistent value to inspect without having to test whether the key exists.

The new property is also declared in the REST API’s ability metadata schema, allowing REST clients to inspect the general exposure intent.

The change does not alter the signature or return value of wp_register_ability() or other Abilities API functions.

Existing channel-specific registrations continue to work:

'meta' => array(
	'show_in_rest' => true,
),

An explicit show_in_rest value remains authoritative. Plugins are not required to replace it with public.

Abilities that previously supplied neither public nor show_in_rest remain unavailable through REST. Their resolved metadata now contains public => false, but their exposure behaviour is unchanged.

Developers should consider migrating from show_in_rest => true to public => true when an ability is generally intended for use by multiple client types. Continue using show_in_rest directly when exposure is intentionally limited to REST or when overriding the general policy.

The following abilities included with WordPress now use meta.public instead of setting meta.show_in_rest directly:

• core/get-site-info
• core/get-user-info
• core/get-environment-info

Their REST availability has not changed. Because public => true supplies the default for show_in_rest, these abilities remain exposed through REST as before.

Using the high-level flag also allows other client integrations to recognise that these Core abilities are intended for external use.

Use public when the ability is generally intended for consumption by external clients.

Use a channel-specific flag when:

• The ability should be exposed through only that channel.
• The ability needs to opt out of a channel despite being generally public.
• A client integration provides behaviour that cannot be represented by the general flag.

The change was introduced in changeset [62729], with Core abilities migrated in changeset [62737]. See Trac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticket Created for both bug reports and feature development on the bug tracker. #65568 for the complete discussion.

Props to @gziolo and @benjamin_zekavica for peer review.

#abilities-api, #7-1, #dev-notes, #dev-notes-7-1, #rest-api