This week’s meeting focused on updating the team on various component progress, including the Abilities API, AI Experiments plugin, and PHP/WordPress AI Clients. A major announcement was the deployment of the MCP adapter on WordPress.com, marking a significant step in dogfooding the new technology.
The primary discussion points centered on scope and definitions for the Abilities API, particularly what constitutes a required vs. optional parameter, and how to define “meta.” The team also had an in-depth conversation about the user experience for AI settings, specifically managing provider credentials and feature toggles, acknowledging the high friction point this represents for users.
Key Highlights
Announcements & Overall Progress
- MCP Adapter on WordPress.com: The MCP (Modular Capabilities Package) adapter has been deployed and is actively being used on WordPress.com, confirming its real-world application.
- Roadmap Review: Tammie Lister proposed wrapping up the roadmap discussion issue to maintain flow and actionability.
- Abilities Repo Health: The Abilities Repository has 11 PRs and 1 draft, with five issues in the current milestone, signaling good progress.
- MCP Repo Structure: Neill McShea and David Levine have scheduled a meeting to clarify and structure the MCP repository information, allowing for more detailed updates in the future.
Abilities API & Scope Management
- Categories Requirement: The team agreed that a grouping mechanism (like “categories”) needs to be a required parameter from the first iteration of the Abilities API.
- Reasoning: This is crucial for future-proofing, ensuring order in a potential “wild west” of abilities, and allowing for filtering when there are thousands of tools in WordPress.
- Meta vs. Root-Level Arguments: A long discussion was held to define a clear boundary for placing arguments in the
metaobject versus at the root level of an ability.- Proposed Definition: Root-level arguments should be for anything required to execute the action (e.g., input/output schema, callback functions). Meta should be for anything descriptive, optional, or speculative/experimental that is not required for execution (e.g., annotations, show in REST, show in MCP).
- Action: Jason Adams will work on a clear, concrete definition to be documented.
- Scope Concern: David Levine raised a concern about “scope creep” and “shipping tech debt,” urging the team to confirm that currently planned speculative features (like annotations) are truly necessary for the first release, given that Core does not easily remove features once they ship.
AI Client Updates
- PHP AI Client (0.2): Felix Arntz is prioritizing the release of a 0.2 version of the PHP AI Client, with most work already complete and just a few outstanding PRs.
- WordPress AI Client (Wrapper): The team needs to make a decision on whether the client wrapper should adjust for WordPress coding standards (e.g., snake_case functions and returning
WP_Error) instead of strictly adhering to PHP’s best practices (camelCase functions and throwing exceptions).
AI Experiments Plugin
- Issues and Mockups: Jeff Paul reported new issues opened, aligning with the roadmap, including the need to wrap up product definition and design mockups for future versions (V0.2 and V0.3).
- Engineering Starts: Engineering work from the Fueled side is scheduled to begin within the next week or so.
- Abilities Integration: The key question remains: which Abilities API features (those that will land in 6.9) will be exposed and built upon within the AI Experiments plugin?
Basic Admin Setting Screen UX
- Two Settings Concerns: There are two main concerns for the settings screen: 1) Provider Credentials and 2) Feature Toggles (enabling/disabling specific AI experiments).
- Centralized Provider Settings: The ideal approach is to have a single, central screen to configure one or more AI providers, which all AI plugins (both Core and third-party) could then leverage. This prevents users from having to enter the same credentials multiple times.
- Component-Based UI: The team discussed the need for reusable UI components that allow individual feature settings pages to either select a pre-configured provider or offer a graceful flow (e.g., a modal) to add a new one without forcing the user to bounce out to the main settings page.
- Friction Point: Tammy Lister and Jeff Paul emphasized that provider setup is the highest friction point for user adoption, requiring an emphasis on clear, informative design, especially regarding token usage and potential costs.