Attendees:
- Jason Adams
- Jeff Paul
- Grzegorz Ziółkowski
- Ovidiu Galatan
Summary
Topics Covered & Recommendations
The discussion focused on defining the structure and scope of the WordPress Core Abilities API, particularly in preparation for the WordPress 6.9 release.
CRUD Operations for Abilities: The group discussed how to handle Create, Read, Update, and Delete (CRUD) operations for post types. It was recommended to move away from a single “CRUD” ability for a given post type. Instead, the recommendation is to break operations into separate abilities to allow for clearer annotations (e.g., marking “delete” as destructive) and to improve how AI models interact with them. Jason noted that “Create” and “Update” could be reliably combined into a single ability, where the presence of an ID parameter would indicate an update. It was recommended that “Read” and “Delete” remain separate abilities.
Handling Different Post Types: A key topic was whether to create a single set of abilities that can operate on any post type via a parameter, or to create discrete abilities for each post type. The group leaned toward recommending the creation of discrete abilities for each post type (e.g., posts, pages). This approach would avoid confusing AI models with WordPress-specific data concepts and the terminology that can arise (e.g., a “post” of type “post”).
Permissions and Security: Grzegorz highlighted the need to account for WordPress’s granular, context-aware permission levels. The current system uses a permissions callback that receives request parameters to make contextual decisions. The group also discussed the idea of an “ability vetting check” to pre-filter abilities based on a user’s role to avoid exposing tools they cannot use.
Ability Organization: Namespaces and Categories: The conversation covered methods for organizing a large number of abilities, especially for AI consumption via a layered tool approach.
Namespaces: It was discussed that namespaces should be used to indicate ownership and prevent naming conflicts.
Categories: It was proposed that categories would group abilities by function. For AI, this allows a model to first request a list of categories and then request the specific abilities within a chosen category, which prevents performance degradation as the number of abilities grows. It was recommended that categories be registered with their own descriptions so the AI can understand their purpose.
Nuances of WordPress Actions: The group noted that standard terms like “delete” have special meaning in WordPress, where an item is typically moved to the trash rather than being permanently deleted. The phrasing and description of abilities must be clear to explain these nuances to an AI.
Next Steps
The primary goal is to finalize the scope of the Abilities API for WordPress 6.9.
Finalize 6.9 Scope: The team needs to decide what a user should be able to accomplish with the API in the 6.9 release to create a cohesive and valuable system from the start. The main tangible use case driving development is the MCP (Multi-Content Platform) adapter.
Implement Core Features for 6.9: Based on the discussion, Grzegorz recommended prioritizing two key features for the next two weeks:
- Ability Filtering: Add the functionality to query for abilities based on criteria like namespace or category.
- REST API Exposure Control: Implement a flag or property that allows developers to prevent an ability from being exposed via the REST API, for abilities intended for server-side use only.
Decide on Required Categories: A decision needs to be made on whether to require a category for every ability registration in version 6.9. Jason advocated for this to ensure the system scales well with a growing number of abilities , while Grzegorz raised the concern that users might just default to an “uncategorized” option.