WordPress Abilities API: Complete Guide For Developers

For the past 20 years, WordPress has been the open web’s leading publishing platform. Its strength lies in its flexibility: themes, plugins, REST APIs, and hooks give developers endless ways to extend it.

But as the web evolves into an AI-driven, workflow-first world, WordPress faces a challenge:
How do external tools, AI assistants, and even other plugins know what WordPress can do?

Right now, the answer isn’t great. Developers rely on:

Reading documentation.
Guessing function names.
Reverse-engineering hooks.
Hardcoding REST endpoints or AJAX calls.

This lack of a unified, discoverable registry of functionality makes it harder for automation, AI tools, and even plugin developers to build interoperable features.

That’s why the WordPress community is building something new: the Abilities API.

Why Abilities API Matters?

Imagine:

An AI assistant that can draft a blog post and schedule it directly in your WordPress site without custom integrations.
A workflow builder that automatically chains actions like “upload image → create gallery → optimize for SEO.”
A plugin ecosystem where each plugin registers its “abilities” in a common language, making discovery and interoperability effortless.

This is what the Abilities API aims to unlock.

It’s not just another developer tool. It’s the foundation for the next generation of WordPress, where humans, plugins, and AI can all “understand” what WordPress can do.

What is Abilities API?

The WordPress Abilities API is a new foundational project being developed as part of the AI Building Blocks initiative. Its purpose is simple yet powerful.

To give WordPress a common, structured way for core, plugins, and themes to describe what they can do (“abilities”) in a machine-readable, human-friendly format.

Instead of having functionality scattered across undocumented functions, hidden hooks, or ad-hoc REST endpoints, the Abilities API creates a central registry of what’s possible inside WordPress.

Scope

According to the official proposal, the Abilities API focuses on:

Discovery → Every ability can be listed, queried, and inspected.
Permissioning → Each ability includes metadata about who or what can invoke it.
Execution metadata → How the ability can be run, what parameters it accepts, and what it returns.

Importantly, the business logic stays inside the registering component (plugin, theme, or core). The Abilities API just provides the structured metadata, the “map” of what’s possible.

Design Goals

The WordPress core team has outlined four design goals for the Abilities API:

Discoverability → Developers, plugins, and AI tools should be able to find out what actions are available without digging through undocumented code.
Interoperability → A uniform schema allows unrelated components to work together in workflows.
Security-first → Abilities are explicitly permissioned. You can’t just run anything, the API makes it clear who/what is allowed.
Gradual adoption → The Abilities API will ship first as a Composer package and then gradually move into WordPress Core, so developers can experiment early without waiting for a major release.

Who It’s For?

The Abilities API is being designed for:

Plugin & Theme Developers → to register their features in a discoverable, standardized way.
Agencies & Enterprises → to build reliable workflows across multiple sites and plugins.
AI & Automation Tools → to dynamically query WordPress for what actions it can perform.

In other words: anyone who wants to know and use what WordPress can do without guesswork.

Inspiration

The Abilities API is inspired by multiple sources:

The Feature API vision → declaring capabilities at the PHP layer.
The Command Palette experiments in Gutenberg → surfacing available actions to users.
Modern AI assistant protocols like Model Context Protocol (MCP) → standardizing how AI tools discover and execute abilities.

Abilities API vs Capabilities API vs REST API

When developers first hear about the Abilities API, the natural reaction is: “Wait, isn’t this just the Capabilities API? Or maybe it’s like the REST API?”

It’s a fair question. To really understand why WordPress needs the Abilities API, let’s break down the differences.

1. Capabilities API (Existing)

Purpose: Defines what users are allowed to do.
Examples: edit_posts, publish_pages, manage_options.
Scope: Server-side permissions tied to roles and users.
Usage: You check if a logged-in user has the right to perform an action.

Capabilities = “Can this user perform this action?”

2. REST API (Existing)

Purpose: Exposes WordPress data and actions over HTTP.
Examples: GET /wp/v2/posts, POST /wp/v2/comments.
Scope: Data access and interaction between WordPress and external systems.
Usage: Allows apps, plugins, and external tools to communicate with WordPress.

REST = “Here’s a structured way to fetch and modify WordPress data remotely.”

3. Abilities API (New)

Purpose: Provides a registry of what WordPress can do, discoverable by both humans and machines.
Examples: “Create post,” “Generate image,” “Approve comment.”
Scope: Metadata about actions: discoverability, permissioning, execution.
Usage: Tells WordPress, plugins, and AI assistants what abilities exist and how they can be used.

Abilities = “Here’s a list of actions WordPress can perform, and who/what can invoke them.”

Putting It Together

Capabilities → Who can do what (permissions).
REST API → How to access and perform actions (endpoints).
Abilities API → What actions exist in the first place (registry).

Think of it this way:

Capabilities are the keys.
REST API is the door.
Abilities API is the map of the entire building.

Without the map, you’re wandering in the dark, you don’t know what rooms (actions) even exist.

Why Not Just Use REST?

One of the most common questions raised (even on This Week in WordPress podcast) is: “Why can’t AI tools just use the REST API?”

Here’s why:

REST APIs are stateless, each request is isolated. AI tools (like LLMs) often need context and multi-step workflows.
REST APIs require pre-knowledge of endpoints. AI assistants need runtime discovery.
REST docs are separate from the endpoints. Abilities are self-describing, making them easier for AI agents to adapt.

In fact, some developers argue that Abilities should power the REST API, not the other way around.

How the Abilities API Works?

The Abilities API is still in development (see the GitHub repo), but its core principle is clear: WordPress needs a structured, discoverable, and secure way to declare what it can do.

Here’s how it works in practice:

1. Abilities Are Registered

Each component (Core, plugin, theme) can register abilities in a structured schema.

Example: A plugin that adds “Like a Comment” can register that as an ability.
The schema includes:
- Ability name.
- Description.
- Parameters.
- Permissions.

This turns hidden functionality into discoverable actions.

2. Abilities Are Discoverable

Once registered, abilities are machine-readable. This means:

Developers can query a list of available abilities.
AI tools (like MCP adapters) can discover what WordPress can do on the fly.
Other plugins can inspect abilities and reuse them in workflows.

Think of it like autocompletion for WordPress actions, no more guessing or digging through docs.

3. Abilities Define Permissioning

Security is built in from the start:

Each ability declares who or what can invoke it.
This could map to existing Capabilities (like edit_posts).
Or define new, finer-grained rules for specific interactions.

Just because an ability exists doesn’t mean everyone can use it.

4. Abilities Expose Execution Metadata

Alongside discovery and permissioning, the Abilities API describes:

What parameters are required.
What output is expected.
Whether it can run on the server (PHP), client (JavaScript), or both.

This metadata makes abilities self-documenting unlike REST, where you often rely on external docs.

5. Unified Access: PHP + JavaScript

One of the most exciting aspects:

Abilities can be executed from PHP (server) or JavaScript (browser).
Same registry, same schema.
This unifies the developer experience across backend and frontend.

Example:

PHP code can check if a user can “Create Post.”
A JavaScript block in the editor can check the same ability before showing a button.

6. Gradual Adoption

The Abilities API isn’t being rushed into Core. Instead:

It’s starting as a Composer package.
Developers can experiment and provide feedback.
Once stable, it will be proposed for WordPress Core.

This “canonical-first, Core when ready” approach ensures quality and broad adoption.

Real-World Use Cases of the Abilities API

The Abilities API isn’t just a fancy new abstraction for developers. It solves real-world problems that WordPress site owners, agencies, and plugin developers face every day. Here are some examples that show its potential:

1. Smarter Comment Moderation

Problem: Right now, moderation tools rely on role checks and UI conditions. If you’re logged in as an Author, you may or may not see “Edit” buttons depending on custom theme logic.

With Abilities API:

“Edit Comment” and “Delete Comment” are registered as abilities.
The system automatically checks whether the current user can see them.
No more scattered if ( current_user_can() ) conditions, it’s standardized.

Result: Cleaner code, consistent UI, better UX for moderators.

2. E-Commerce Product Controls

Problem: WooCommerce buttons like “Add to Cart” or “Apply Coupon” are often handled with custom templates and JavaScript checks. Developers reimplement the same logic over and over.

With Abilities API:

“Add to Cart” is an ability with a check: product must be in stock.
“Apply Coupon” is an ability gated by whether the coupon is valid for the user.
Frontend automatically hides or disables buttons when unavailable.

Result: Dynamic, context-aware e-commerce UI without custom conditionals.

3. Membership & Subscription Sites

Problem: Restricting content or downloads often requires multiple plugins with different logic for gating access.

With Abilities API:

“Download PDF” is registered as an ability.
Ability check = whether the user’s membership level includes that file.
Templates automatically adapt, no manual role checks.

Result: Easier to build and maintain subscription sites with consistent permissions.

4. Workflow Automation for Agencies

Problem: Agencies often build client workflows that connect multiple plugins. But integrating them is brittle because each plugin uses different APIs.

With Abilities API:

Plugin A registers “Generate Invoice.”
Plugin B registers “Send Email.”
Plugin C registers “Log to CRM.”
An automation tool (or AI agent) can discover these abilities and chain them into a workflow.

Result: Seamless cross-plugin automation without custom glue code.

5. AI Agents & Assistants

This is where it gets futuristic.

Problem: AI assistants (like ChatGPT or Claude) need to know what actions are possible in WordPress to help users automate tasks. REST APIs aren’t designed for this kind of dynamic discovery.

With Abilities API:

An AI agent can query available abilities:
- “Create Post”
- “Upload Media”
- “Publish Draft”
The agent can then offer to do these tasks directly, without needing hardcoded integrations.

Result: WordPress becomes AI-native, ready for intelligent assistants and workflow builders.

6. Consistent UI Across Themes

Problem: Themes and plugins often reinvent the wheel when showing or hiding UI controls. This creates inconsistent user experiences.

With Abilities API:

The theme doesn’t need to know the business logic, it just checks the ability.
Example: Show “Edit Post” button only if canEditPost is true.
This keeps UI consistent across any theme.

Result: Themes become lighter, UIs become more predictable.

These use cases show that the Abilities API is more than an AI play, it’s about making WordPress cleaner, more consistent, and future-proof for both human users and machine agents.

Why the Abilities API Matters for AI and MCP?

The Abilities API is not being built in a vacuum. It’s part of a bigger effort to prepare WordPress for the AI-powered future of the web.

At the heart of this is the Model Context Protocol (MCP), an open standard released in 2024 by Anthropic and now adopted by OpenAI, Google DeepMind, and other AI leaders. MCP gives AI assistants a universal way to connect to external tools, data sources, and workflows.

Why REST APIs Aren’t Enough

A common question from developers is: “Couldn’t AI tools just use the WordPress REST API?”

Here’s why that falls short:

REST is stateless → Each request is isolated, but AI agents often need multi-step, context-aware workflows.
REST requires pre-knowledge → Developers must hardcode endpoints, but AI needs runtime discovery of what’s possible.
REST lacks self-documentation → Endpoints are described in separate docs, while MCP (and Abilities API) embed definitions directly.

In other words, REST works great for apps, but not for AI assistants that need to adapt on the fly.

How Abilities API Fit Into MCP?

The Abilities API creates the structured registry of actions that MCP implementations need.

Without abilities: MCP servers must guess or hardcode which functions exist in WordPress.
With abilities: WordPress can present a machine-readable list of everything it can do.

For example, an MCP-powered AI assistant could:

Query WordPress abilities → sees “Create Post,” “Upload Image,” “Publish Draft.”
Ask the user: “Do you want me to create a new post and publish it for you?”
Execute the workflow safely with permission checks.

Flexibility for Future Protocols

Another key design goal: don’t tie WordPress to MCP forever.

The Abilities API serves as the foundation. Then, adapters (like the MCP Adapter) can expose abilities to different standards.

Today → MCP Adapter for AI assistants.
Tomorrow → A different protocol could be supported without rewriting everything.

This ensures WordPress stays adaptable, no matter how the AI ecosystem evolves.

What This Unlocks

By combining Abilities API + MCP, WordPress can:

Power AI agents that help with publishing, moderation, and workflows.
Enable no-code workflow builders where users chain actions together.
Provide context-aware AI assistants inside the editor (e.g., suggesting SEO tweaks, formatting, or media).
Let external AI platforms (like Claude or ChatGPT) directly interact with WordPress safely.

Essentially, it transforms WordPress from a CMS into an AI-ready operating system for the open web.

Best Practices for Developers

As the Abilities API moves from prototype to adoption, developers will play a critical role in shaping how it’s used. The key to success isn’t just registering abilities, but doing so in a way that’s secure, consistent, and interoperable across plugins, themes, and AI tools.

Here are some best practices every WordPress developer should follow:

1. Keep Security First

Abilities describe what’s possible, but they shouldn’t bypass WordPress’s existing Capabilities API.
Always map ability permissions to real user capabilities (edit_posts, moderate_comments, etc.).
Example: A “Delete Comment” ability should check both login state and current_user_can( 'moderate_comments' ).

Treat abilities as UI/interop hints, not replacements for backend security.

2. Be Descriptive and Human-Friendly

Each ability should include:
- A clear name (myplugin.deleteComment).
- A short description (“Deletes a comment if the user is a moderator”).
- Parameter metadata (types, requirements, examples).
This helps both developers and AI agents understand what the ability does.

Think of it like writing documentation directly into the registry.

3. Keep Abilities Atomic

Register small, focused abilities rather than giant multi-step workflows.
Example: Instead of “Generate and Publish Blog Post,” register:
- createPost
- uploadMedia
- publishPost
This makes it easier to compose workflows later (e.g., AI chaining actions).

4. Avoid Duplicates Across Plugins

If multiple plugins offer similar actions, consider adopting shared naming conventions.
Example: uploadImage shouldn’t also exist as addMediaFile in another plugin.
A community-driven schema may emerge (like schema.org for structured data).

This is where agencies and plugin authors can collaborate for consistency.

5. Think Cross-Platform

Remember: abilities aren’t just for your plugin. They may be consumed by:
- Themes (for conditional UI rendering).
- Other plugins (for workflow automation).
- AI agents (for dynamic action discovery).
Write abilities as if other developers will reuse them.

6. Test in Both PHP and JS

If you register an ability in PHP, test that it’s accessible in JavaScript as well.
Many modern features (block editor, frontend interactivity) rely on JS checks.
Ensure consistent behavior across server and client.

7. Document Your Abilities

Even though abilities are self-describing, add extra documentation in your plugin/theme docs.
Example: provide usage examples for developers who want to integrate.
Bonus: this builds trust with agencies adopting your plugin.

8. Stay Updated with Core Discussions

The API is still evolving, join the #core-ai Slack channel for updates.
Monitor the Abilities API GitHub repo.
Share feedback and use cases early, so your needs shape the final spec.

Current Status & How to Get Involved?

The Abilities API is still early in its journey, but development is moving fast. Here’s where things stand today (as of mid–2025):

Current Status

According to the official Make WordPress AI blog and the GitHub repo:

Placeholder repository → Created.
Spec draft → In progress.
Prototype plugin & Composer package → In progress.
Community feedback → Planned in the #core-ai Slack channel.
Core proposal → Planned after prototypes are tested.

The plan is to release the Abilities API first as a Composer package, so developers can experiment and give feedback without waiting for a WordPress Core merge.

How to Get Involved?

If you’re a developer, agency, or plugin author, now is the perfect time to help shape the Abilities API. Here’s how:

Join the Discussion
- Participate in the #core-ai Slack channel.
- Share your use cases (e.g., eCommerce actions, content workflows).
Experiment with the Prototypes
- Watch the Abilities API GitHub repo.
- Test the upcoming Composer package in your plugins or themes.
Contribute Use Cases & Feedback
- Open issues on GitHub with examples of how you’d use the API.
- Help refine naming conventions and schema standards.
Build Adapters & Experiments
- Try connecting abilities to workflow builders, AI agents, or even your own automation tools.
- Share demos to show what’s possible.

Why Your Feedback Matters?

The Abilities API is designed to be extensible and community-driven. That means:

Plugin authors can shape how abilities are named and structured.
Agencies can push for features that support real-world client needs.
AI developers can ensure the API works well with tools like MCP.

Early involvement ensures the API evolves into something that everyone in the WordPress ecosystem benefits from.

Conclusion: A New Era for WordPress

The Abilities API is more than just another developer tool, it’s a paradigm shift for WordPress.

For years, plugins, themes, and even Core itself have relied on a patchwork of hooks, functions, and REST endpoints to describe functionality. That worked fine for human developers, but it left gaps for:

Interoperability → Plugins couldn’t easily discover each other’s features.
AI tools → Assistants like ChatGPT or Claude couldn’t dynamically explore what WordPress could do.
Consistency → Frontend UIs often had to “guess” which actions were available to which users.

The Abilities API changes all that. By creating a central registry of what WordPress can do, with structured metadata, permissions, and discoverability, it prepares WordPress for the next generation of publishing:

Smarter, more consistent user interfaces.
Seamless plugin interoperability.
AI-native workflows and assistants.

Why This Matters for You

If you’re a:

Plugin developer → The Abilities API makes your features discoverable and reusable by other plugins, themes, and AI tools.
Agency builder → It unlocks easier workflow automation across multiple sites.
Business owner → It prepares your WordPress site to integrate with AI-driven tools and assistants.

This isn’t just future-proofing. It’s a chance to push WordPress beyond being “just a CMS” into becoming the operating system of the open web.

What’s Next

The Abilities API is still evolving. You can:

Follow development on the GitHub repo.
Join the #core-ai Slack channel to contribute ideas.
Keep an eye on updates at Make WordPress AI Blog.

How I Can Help

As a Certified WordPress Expert, I specialize in building modern WordPress solutions from plugin development to workflow automation. If you want to: