WordPress Abilities API: A Practical Setup and Audit Guide

The WordPress Abilities API gives plugins a structured way to expose specific actions, such as reading SEO data or publishing a post, so that AI tools and automation scripts can discover and run them safely. It shipped in WordPress 6.9 and sits quietly in core on every site running that version or newer, including the WordPress 7.1.3 release most sites are on today. This guide walks through how to check whether it is active, see what is already exposed on your install, and lock down anything that should not be public, in eight concrete steps.

If you run Yoast SEO, Rank Math, WPForms, or the official WordPress MCP Adapter plugin, there is a good chance the WordPress Abilities API is already doing work on your site without anyone having reviewed it. Yoast’s October 13 release notes, for instance, describe new fields that let an AI tool update a post’s SEO title, meta description, and social previews directly through an ability named yoast-seo/update-post-seo-data. That is useful. It is also exactly the kind of feature a site owner should understand before an AI agent starts using it.

What the WordPress Abilities API Actually Does

An “ability” in WordPress terms is a small, named unit of functionality with a defined input, a defined output, and a permission check attached to it. Developers register one with the wp_register_ability() function, which has been part of core since WordPress 6.9. Each ability needs a namespaced name such as my-plugin/summarize-notes, a category, an execute_callback that does the work, and a permission_callback that decides who is allowed to run it.

The point of the WordPress Abilities API, as WordPress’s own developer documentation describes it, is discoverability. Instead of an AI agent guessing which REST routes exist or scraping the admin screens, it can ask the site “what can you do?” and get back a structured list of abilities with their input and output schemas. The WordPress MCP Adapter plugin, built by contributors on the Make WordPress AI team, connects that registry to the Model Context Protocol (MCP), the standard several AI assistants use to talk to external tools. Once that bridge is in place, a connected AI client can see every registered ability and call the ones it has permission to use.

The WordPress Abilities API is a different layer from the REST API authentication you set up with application passwords. Authentication decides whether a request is allowed to reach your site at all. The Abilities API decides what a successfully authenticated request is allowed to do once it is in, and in what shape. If you have not reviewed how AI tools authenticate to your WordPress install yet, it is worth doing that first and treating this guide as the next layer on top.

Step 1: Confirm the WordPress Abilities API Is Active on Your Site

Check your WordPress version first. The Abilities API needs WordPress 6.9 or later, and it ships as part of core, so there is nothing separate to install. Open Dashboard, then Updates, or check the version number at the bottom of your admin screens.

If you are already on 7.1.x, you have it. A quick way to confirm from code is to check for the class WordPress registers internally:

• Open a site health or debug tool that can run a one-off PHP snippet, or use WP-CLI if you have shell access.
• Check whether the WP_Abilities_Registry class exists. If it does, the registry is live.
• Note your exact version number for later, since the REST endpoint’s filtering options changed between 6.9 and 7.1, and keep an eye on the WordPress 7.2 release notes once that version ships, in case core adds more.

I ran this check directly on a WordPress 7.1.3 install that runs Rank Math SEO Pro and WP Mail SMTP, and the registry already held 76 separate abilities, most of them from Rank Math’s SEO toolset and a handful from core and WP Mail SMTP. None of that required installing anything extra. It was already there.

Step 2: Find Out Which Plugins Already Register Abilities

Not every plugin uses the Abilities API yet, but adoption is moving fast among SEO and automation-heavy tools. Yoast SEO, Rank Math, and WPForms have all published abilities, and more plugins add them with every release. The practical way to find out what is on your site is to list the plugin folders that reference the registry.

From your WordPress root, search your wp-content/plugins directory for files that call wp_register_ability or hook into wp_abilities_api_init. Any match is a plugin exposing at least one ability. If you manage the server through SSH, a simple recursive grep across the plugins folder takes a few seconds and tells you exactly which plugins to look at more closely.

Without shell access, check each active plugin’s changelog for the word “abilities.” Yoast, for example, documents every ability it ships, including the exact fields each one reads or writes. That is more reliable than guessing from the settings screen, since abilities are not always visible in the admin UI at all.

Step 3: List Every Registered Ability on Your Site

Once you know the registry is active, the next step is seeing the full list. WordPress core exposes two REST routes for this:

• GET /wp-json/wp/v2/abilities lists every ability registered on the site, and accepts a category query parameter to filter the results.
• GET /wp-json/wp/v2/abilities/{name} returns the full schema for one ability, using its namespaced name, such as core/get-site-info.

Hit the list endpoint from a browser tab while logged in as an administrator, or with an authenticated request through a tool like Postman or curl if you want to see it exactly as an AI agent would. You will get back each ability’s name, label, description, category, and whether it is exposed through REST at all. Abilities that were registered without show_in_rest set to true will not appear here, which is normal. Those are still callable from inside WordPress by other PHP code, just not reachable over HTTP.

Read through the list slowly the first time. On most sites it is longer than people expect, because core itself registers a handful of baseline abilities such as core/get-site-info and core/get-user-info, and every active plugin that has adopted the WordPress Abilities API adds more on top.

Step 4: Check the Permission Callback on Each Ability

This is the step most people skip, and it is the one that matters most for security. Every ability is supposed to have a permission_callback that WordPress runs before the ability’s main code executes. A well-built ability ties that callback to a specific capability, such as manage_options or edit_posts, rather than just checking that a user is logged in.

For abilities that ship with a reputable plugin, the permission check is usually sound, since the plugin’s own developers have a reason to keep it tight. The risk shows up with smaller or less-maintained plugins, custom abilities written in-house, or anything migrated quickly from an old REST endpoint without re-checking the permission logic. Ask these questions for each ability you find:

• Does the permission callback check a specific capability, or does it only confirm the user is logged in?
• Does the ability write data (like updating a post) or only read it? Write abilities deserve a tighter check.
• Is the ability marked public in its meta array? A public ability can be more visible to automated discovery, so it should have the strictest permission logic of all.

If a plugin’s ability fails any of those checks, that is a reason to contact the plugin author or hold off on connecting an AI tool to that part of the site until it is patched.

Step 5: Test an Ability Safely Before You Trust It

Before letting any AI client run a WordPress Abilities API call for real, test it yourself on a staging copy of the site, not production. Call the single-ability REST route to read its input and output schema first, so you know exactly what data it expects and what it returns.

For a read-only ability, such as one that fetches SEO scores or link reports, testing is low risk. Run it as a logged-in administrator and confirm the output matches what the schema promised. For a write ability, such as Yoast’s post SEO update ability, test with a throwaway post on staging first. Check that it only changes the fields it claims to change, and that the focus keyphrase or other fields you expect to stay untouched actually do.

Keep a short note of which abilities you have tested and verified. That list becomes useful later when deciding which abilities an AI agent can use unattended, versus which ones still need a human to review the result.

Step 6: Decide What Stays Private vs. What Goes Public

Every ability in the WordPress Abilities API has a choice baked into its registration: whether it shows up in REST discovery at all, and whether its meta marks it public. Treat this the same way you would treat a REST endpoint or a webhook. Public, broadly discoverable abilities should only cover actions you are comfortable with any connected AI tool finding and potentially calling, within the limits of its permission check.

I usually recommend starting conservative: leave custom abilities set to non-public and require show_in_rest only for the ones you actually want external tools to see, then open them up one at a time as you confirm each one behaves the way its schema claims. It is far easier to widen access later than to walk back something an automated tool already used.

Step 7: Register a Custom Ability If You’re a Developer

If you want your own plugin or theme to expose functionality through the WordPress Abilities API, the pattern is short. Register a category first, then register the ability itself, both inside their dedicated init hooks:

add_action( 'wp_abilities_api_categories_init', function( $registry ) {
    wp_register_ability_category( 'site-maintenance', array(
        'label' => __( 'Site Maintenance', 'my-plugin' ),
    ) );
} );

add_action( 'wp_abilities_api_init', function( $registry ) {
    wp_register_ability( 'my-plugin/clear-transient-cache', array(
        'label'               => __( 'Clear Transient Cache', 'my-plugin' ),
        'description'         => __( 'Deletes expired transients from the options table.', 'my-plugin' ),
        'category'            => 'site-maintenance',
        'permission_callback' => function() {
            return current_user_can( 'manage_options' );
        },
        'execute_callback'    => 'my_plugin_clear_transients',
        'meta'                => array( 'show_in_rest' => true, 'public' => false ),
    ) );
} );

Calling wp_register_ability() outside the wp_abilities_api_init hook triggers a “doing it wrong” notice and returns null, so keep registration inside that hook even in small plugins. Add input and output schemas using JSON Schema syntax whenever the ability takes parameters or returns structured data, since that schema is what lets an AI client understand how to call it correctly without trial and error.

Step 8: Log and Monitor Ability Usage Going Forward

Once your WordPress Abilities API audit is done, keep an eye on how abilities get used going forward. Core fires two hooks around every execution: wp_before_execute_ability, right after the permission check passes, and wp_after_execute_ability, once the callback finishes and its output has been validated against the schema. Both pass the ability’s name and input, and the second also passes the result.

A simple logging function hooked to wp_after_execute_ability, writing the ability name, the current user, and a timestamp to a log table or file, gives you an audit trail with very little code. For sites that connect AI agents to perform real changes, such as updating SEO fields across a large content library, that log answers “what did the AI actually do, and when” after the fact.

Common Mistakes With the WordPress Abilities API

A few WordPress Abilities API mistakes show up often enough to flag:

• Assuming an ability is safe because the plugin that ships it is well known. Check the permission callback yourself; do not take it on faith.
• Marking a write ability public before testing it on staging with throwaway content.
• Forgetting that abilities without show_in_rest are still callable from inside WordPress by other plugins, even though they will not appear in the REST list.
• Confusing ability permissions with REST API authentication. An application password gets a request in the door; the permission callback decides what it can touch once it is there.
• Registering abilities outside the wp_abilities_api_init hook, which silently fails in current WordPress versions.

Frequently Asked Questions

Which WordPress version do I need for the Abilities API?

WordPress 6.9 or later. It is part of core, so there is no separate plugin to install for the base registry itself, though tools like the WordPress MCP Adapter add a protocol bridge on top of it.

Does the Abilities API replace the REST API?

No. It sits alongside the REST API and reuses much of its infrastructure. Abilities are a more structured, permission-aware way to expose specific actions, while the broader REST API still handles general data access for posts, users, and other objects.

Can I disable the Abilities API if I do not want it?

There is no single settings toggle in core. The safest approach is auditing which abilities are registered and public, as covered above, and working with each plugin’s own settings or filters to restrict or unregister the ones you do not want exposed.

Is the WordPress Abilities API a security risk by itself?

The API itself enforces permission checks before every execution, so it is not inherently less safe than any other part of WordPress. The risk comes from individual abilities with weak or missing permission logic, which is exactly why Step 4 and Step 5 above matter.

Why This Matters and What to Do Next

AI tools connecting to WordPress sites is not a future scenario. It is already happening through plugins you likely have installed. The WordPress Abilities API is the layer that decides what those tools can see and do once they are authenticated, which makes it worth a deliberate review rather than something you discover after the fact.

Start by checking your WordPress version and running the registry check from Step 1. Pull the full list from/wp-json/wp/v2/abilities, read through what is already there, and flag any write ability that lacks a specific capability check. Set a reminder to repeat this audit after major plugin updates, since new abilities tend to arrive quietly inside routine changelogs rather than headline announcements.