The WordPress Abilities API  ## Metadata - Author: [[Jonathan Bossenger]] - Full Title: The WordPress Abilities API - Category: #articles - Document Note: --- tags: - #WordPress - #AbilitiesAPI - #AIintegration Author: Jonathan Bossenger Source: Jonathan Bossenger blog Reference: https://jonathanbossenger.com/the-wordpress-abilities-api/ date created: 2025-08-16 13:15 --- # Title: The WordPress Abilities API ## Table of Contents: - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📖 References](#-references) - [🗣️ Paraphrase](#-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [♿ Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [🔍 Logical validity](#-logical-validity) - [🔍 DARVO Analysis](#-darvo-analysis) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) --- ## ​ Summary: Jonathan Bossenger explains why WordPress needs an **Abilities API**—a structured registry of discoverable core, plugin, and theme capabilities—to support AI integration via protocols like MCP. Without it, each implementation must reinvent how to expose functionality, risking fragmentation and future incompatibility. A centralized registry empowers consistent, extensible interaction across the ecosystem. --- ## ​ Main Content: Bossenger reflects on feedback from the *This Week in WordPress* podcast: listeners often confuse Abilities API with the REST API. He clarifies that while REST endpoints are expressive, they are incomplete and ad-hoc, particularly for AI use. The Model Context Protocol (MCP) exposed this limitation by demanding a machine-readable way to enumerate capabilities across systems. What emerged is a call for a unified registry that both humans and machines can rely on. ### ​​ Notes - **Podcast trigger** — discussion on WP Builds sparked listener questions about the Abilities API. - **Clarification needed** — abilities ≠ REST endpoints; broader scope, purpose, and structure. - **REST API limitations** - Endpoints only document limited functionality. - AJAX and internal hooks add functionality invisibly. - This leads to unpredictability and fragmentation for AI/integration tooling. - **MCP as catalyst** - Exposed inability to discover functionality uniformly. - Highlighted the need for structured metadata about capabilities. - **Abilities API purpose** - Central registry of abilities (actions WP *can do*) - Machine- and human-readable definitions of what components can do. - Supports discovery, security, automation, and AI orchestration. - **Future alignment** - Enables plugins/themes to declare abilities for use by MCP, automation, command palettes, etc. - Promotes ecosystem-wide composability and adaptability. --- ## ​ References: - Jonathan Bossenger, “The WordPress Abilities API,” personal blog post - Make WordPress AI: “Abilities API” overview and examples :contentReference[oaicite:0]{index=0} - GitHub “WordPress/abilities-api” repository specifying purpose and design goals :contentReference[oaicite:1]{index=1} --- ## ​​ Paraphrase: 1. **Original**: “This is a question I see a lot when I talk to people about WordPress and AI... I thought it might be worthwhile documenting my understanding of why WordPress needs the Abilities API.” **Paraphrase**: Many confuse the Abilities API with the REST API. To clarify its unique value—especially in AI scenarios—I’m laying out my understanding of what it brings to WordPress. 2. **Original**: “It would be pretty easy to build and implement an MCP server... Each solution has a similar foundational problem: there’s currently no structured registry of WordPress Core abilities...” **Paraphrase**: While implementing a WordPress MCP server is feasible, the real blocker is there’s no organized list of WP abilities to hook into—so every solution ends up reinventing how features are exposed to AI or automation layers. --- ## ​ Newsletter: **This week’s insight: WordPress may be talking, but AI doesn’t understand yet—enter the Abilities API.** Jonathan Bossenger explains why WordPress needs a structured registry of capabilities—what it *can do*—for AI protocols like MCP to communicate meaningfully. REST APIs don’t cut it: hidden AJAX and internal hooks are invisible to automation layers. The Abilities API gives plugins, themes, and core a way to formally register abilities, primed for AI, command palettes, and orchestration tools. Imagine AI-assisted workflows where your SEO plugin can say, “I can score content”—and get invoked reliably. Want to build the future of WP + AI? This is your blueprint. --- ## ​ Action Items: - Review integration points in GoDaddy’s Developer Advocate workshops to incorporate the Abilities API as foundational for AI tooling. - Pilot a plugin exposing abilities via the API to demonstrate command palette and automation flow. - Engage in the `#core-ai` Slack channel to contribute to schema discussions and cross-project alignment. - Include an “Abilities API quickstart” segment in WordPress educational content and OSPO outreach materials. --- ## ​ Hypotheses: - H1: Adoption of Abilities API will accelerate AI-driven features by reducing fragmentation in capability discovery. - H2: Developers integrating via Abilities API will experience fewer breakages when switching protocols (e.g., MCP to another standard). - H3: Plugin ecosystems that expose abilities will have higher automation adoption among WP sites. --- ## ​ Methodology: - Compare development velocity of AI integrations using ad-hoc discovery versus the Abilities API. - Survey plugin authors before/after using the API on ease-of-use and reliability. - Measure interoperability across multiple plugins enabling workflows via Abilities API. --- ## ​ Questions: - How will the API handle versioning and deprecation across core/plugin abilities? - What governance ensures consistent, secure registration of abilities across ecosystems? - Could metadata schemas support behavioral descriptions, input/output contracts, and locale? --- ## ​ Future Research: - Track ecosystem adoption of Abilities API and MCP adapter across key plugins. - Evaluate the UX of AI automations—does ability declarative registration improve discoverability? - Explore governance models for ability schema evolution and cross-project alignment. --- ## ​ Implications: The Abilities API could evolve WordPress into an orchestratable platform—not just CMS, but AI-native platform. For WP educators, this becomes a key vocabulary: “register your capability for AI,” shifting mental models toward interoperability and automation readiness. --- ## ​ Learning Styles Assessment: - **Visual** - Present: Minimal visuals in article. - Improve: Diagrams showing REST vs. Abilities registry + MCP flow. - **Aural** - Present: Written post only. - Improve: Add audio summary or narrated demo. - **Verbal** - Present: Clear explanations. - Improve: Glossary of terms (MCP, ability, registry). - **Kinesthetic** - Present: Code concept only. - Improve: Interactive plugin demo or sandbox to register abilities. - **Logical** - Present: Logical explanation of limitations and solution. - Improve: Include side-by-side schema comparisons. - **Social** - Present: Encourages Slack discussion. - Improve: Host group ideation sessions for ability use-cases. - **Solitary** - Present: Reflective post. - Improve: Provide guided reflection prompts or self-driven exercises. - **Naturalistic** - Present: None. - Improve: Use metaphor like abilities as “building blocks in a connected city”. --- ## ​ Accessibility Assessment: - Use of headings aids screen readers. - Improve: Ensure alt text for code blocks or visuals if added. - Ensure logical reading order and keyboard navigability on the blog page. --- ## ​ DEIB Assessment: - Content is technical but inclusive. - Improve: Offer simplified summaries for non-technical readers; ensure l - Summary: 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… - URL: https://jonathanbossenger.com/the-wordpress-abilities-api/?utm_source=newsletter.loopwp.com&utm_medium=newsletter&utm_campaign=issue-170-loop-wp close up shot of a usb port beside a laptop 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](https://wpbuilds.com/2025/08/12/this-week-in-wordpress-344/). During the podcast we discussed the [Abilities API](https://github.com/WordPress/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](https://modelcontextprotocol.io/docs/getting-started/intro) (aka MCP) was released in November 2024 by [Anthropic](https://www.anthropic.com/) 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](https://modelcontextprotocol.io/), 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](https://github.com/modelcontextprotocol/servers?tab=readme-ov-file#-third-party-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](https://github.com/Automattic/wordpress-mcp), as did [a team lead by Pascal Birchler](https://pascalbirchler.com/wordpress-model-context-protocol-mcp/) at [CloudFest Hackathon](https://hackathon.cloudfest.com/). 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](https://github.com/Automattic/wp-feature-api), now known as the [Abilities API](https://github.com/WordPress/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., The WordPress Abilities API, Jonathan Bossenger, 01k2hsqkq4nf36sszbvkjfapgp.