Jonathan Bossenger

This past Monday I guested on the This Week in WordPress podcast by my friend Nathan Wrigley. If you missed it, you can catch the episode here.

During the podcast we discussed the Abilities API. As I explained more about the related pull request, one of the listeners, Mark Wilkinson, asked:

​​What is an ability? Can you give an example?

After my explanation, he followed up with:

​​Interesting and a good explanation thank you. Sounds like the REST API though.

This is a question I see a lot when I talk to people about WordPress and AI, and so I thought it might be worthwhile documenting my understanding of why WordPress needs the Abilities API.

Model Context Protocol

If you haven’t been following all the recent news in the AI space, the Model Context Protocol (aka MCP) was released in November 2024 by Anthropic to standardize the way artificial intelligence (AI) systems like large language models (LLMs) integrate and share data with external tools, systems, and data sources.

MCP provides a universal interface for reading files, executing functions, and handling contextual prompts. Before MCP developers often had to build custom connectors for each data source or tool.

You can read more about the protocol on the official MCP website, but the important bit to understand is that MCP has been adopted by all the major AI providers, including OpenAI and Google DeepMind.

Essentially, if you’re using any AI assisted tool or building an AI powered application, and you want to be able to give it any type of external context without having to add it manually, MCP is currently the way to do it.

The list of community MCP servers that has been built since the protocol was launched is quite lengthy, and includes everything form GitHub to Xero.

Why can’t LLMs just use existing REST APIs?

Most applications, especially those on the web, have some form of REST API. So why can’t LLMs or AI tools simply use REST? The core reason is that REST APIs are not designed with the needs and behaviors of LLMs in mind. 

While REST APIs are stateless (they treat each request in isolation) LLM-powered agents often need to maintain conversational context and share state across steps in a task. MCP avoids the limitations of statelessness by maintaining a persistent, real-time connection that allows for rich, context-aware workflows, enabling multi-step reasoning and action without losing state.

REST APIs also require clients to know all endpoints and their capabilities in advance, which makes adapting to changes slow and manual. MCP, on the other hand, supports runtime discovery, letting an LLM query available tools on the fly, automatically understand new capabilities, and adapt without needing code changes whenever the backend evolves.

With REST APIs, the documentation often lives separately from the endpoints themselves, requiring manual updates when the API changes. MCP embeds self-describing definitions for tools directly within the protocol, so LLMs automatically understand capabilities, expected parameters, and constraints.

Why bother with the Abilities API?

Why not just build a core WordPress MCP server implementation, and be done with it?

It would be pretty easy to build and implement an MCP server solution for WordPress. Automattic built one, as did a team lead by Pascal Birchler at CloudFest Hackathon. The Automattic solution makes use of core WordPress APIs, including some REST API endpoints, to power it’s MCP tools, resources and prompts, and the Cloudfest project uses WP CLI commands for the same reason.

Each solution has a similar foundational problem: there’s currently no structured registry of WordPress Core abilities that it can build on top of to surface these abilities to the MCP server implementation.

Additionally, if additional functionality is ever added to WordPress Core, each of these solutions would have to create a new way of exposing this functionality in their MCP implementation. Not only that, but how should plugins or themes register their abilities to an MCP server implementation?

And finally, what happens if a different protocol is suggested, developed, and eventually adopted as the new standard by all AI companies? We’ve all followed the USB cable/connector debacle of the last decade or so. How does the WordPress project make sure that it’s easy to replace an MCP implementation with whatever might come next.

MCP exposed the flaws in the system

Ironically, it was the attempts to develop a WordPress MCP implementation that exposed this fundamental problem.

Historically, WordPress core has added many core functionalities through internal functions, that serve developers requirements well. On top of that, the hooks system allows extensibility and a nice level of customization.

When the REST API was introduced, it added a certain level of clarity about specific parts of the system that can be read or modified remotely. However, you don’t necessarily want to create a new REST API endpoint for every user interaction, so developers often rely on AJAX to solve problems faster.

That creates the issue that any functionality created in this way isn’t easy to discover or extend.

The development of an MCP implementation exposed the fact that WordPress doesn’t have a low-level system that allows developers to use a systematic approach when registering any functionalities, and thus the Feature API, now known as the Abilities API, was born.

Interestingly, if you take this all a step further, if the Abilities API is merged into Core, it should be the thing that powers the REST API, not the other way around. I’m not sure if that would ever happen, but it’s interesting to think about.

What the Abilities API unlocks

By using the Abilities API, functionality can be registered in one place using a structured API, and documented in a way that other developers can browse and use it.

The same functionality can be executed on the server (PHP) and from the browser (JavaScript) with a simple unified API.

The added bonus is that not only can developers browse and use these Abilities, but so can LLMs, creating a solid foundation for the next evolution of WordPress.

With thanks to Greg Ziółkowski for his input on this post.