Building on the Abilities API and three read-only core abilities (core/get-site-info, core/get-user-info, core/get-environment-info) shipped in 6.9, WordPress 7.0 brings the server-side WP AI Client. Together these form the baseline: a way to declare what WordPress can do, and a way to connect to providers that reason about it.
This post outlines what I’d like to see developed next for WordPress 7.1 and beyond across Guidelines, Abilities API, WP AI Client, and related infrastructure. Some of these have Trac tickets filed, some have proposals posted on GitHub, and some are still in active research.
The MCP Adapter (server and client) isn’t covered here, as it doesn’t target WordPress core yet. First, it needs a 1.0 release in the WordPress Plugin Directory, with real-world usage before proposing for core inclusion.
Guidelines — Gutenberg 22.7 experiment
Guidelines shipped as a Gutenberg experiment in 22.7. The feature provides a Settings page with guideline categories, block-level guidelines, and import/export with revision history. Storage is a CPT with categories as post meta and REST endpoints gated behind manage_options.
Architectural feedback has driven a refactor that’s in flight. The CPT name (wp_guideline) is settled, and a wp_guideline_type taxonomy has been introduced and should replace the post meta approach for categories — bringing registration, REST filtering, admin UI, and plugin interoperability for free. Two items I’d still like to see land before the core merge. First, file-based defaults for themes following the wp_template pattern, where themes provide file-based defaults and user customizations get stored as CPT posts. Second, a plugin API in initial scope so wp_register_guideline() ships with the merge rather than being deferred to a follow-up.
Abilities API
Execution lifecycle filters — Trac #64989
The Abilities API currently has no way for plugins to intercept or modify ability execution. The AI plugin and MCP Adapter both need this for logging, permission overrides, input transformation, and result modification.
The ticket proposes four filters (wp_pre_execute_ability, wp_ability_normalize_input, wp_ability_permission_result, wp_ability_execute_result) placed inside operational public methods, not inside getters. A failure filter (wp_ability_execution_failed) is explicitly scoped out for a separate future ticket.
Abilities filtering — Trac #64990
The current wp_get_abilities() returns all registered abilities with no way to filter by category, namespace, or metadata. This is already causing ecosystem workarounds. WooCommerce maintains its own filter, the MCP Adapter uses explicit allow-lists, and the WebMCP adapter prototype hardcodes visibility. These ad-hoc solutions are reliable signals that filtering belongs in the API itself.
The design converges on extending the existing function with an optional $args parameter supporting category, namespace, and meta filtering, plus a filter_callback escape hatch. This extends rather than replaces wp_get_abilities(), preserving backward compatibility. The research on architecting tools at scale identifies filtering as the foundational piece that enables progressive disclosure, and also covers related concerns like ability consolidation patterns and description quality conventions for the ecosystem.
New core abilities — WordPress/ai#40
Settings
The direction has converged on a broad-first approach: generic core/get-settings / core/update-settings as the primary interface, with specialized abilities where the generic shape doesn’t serve a domain well. core/get-site-info stays as shipped in 6.9, with a no-duplication rule between generic and specialized abilities. A deprecation path is tracked in Trac #64209. Implementation work in wordpress-develop#10747 and wordpress-develop#10892.
User management
The proposal expands core/get-user-info with additional profile fields (first_name, last_name, nickname, description, user_url) and adds a new core/update-user-info write ability scoped to the current user. Sensitive fields (user_email, user_pass, roles) are excluded. Field naming follows WP-CLI conventions.
Site orientation
Three read-only abilities proposed to complete the “site orientation” layer started in 6.9:
core/get-active-theme— what’s the presentation layer?core/list-plugins— what’s installed?core/get-site-health— aggregates Site Health tests into a single structured response.
Together with the three 6.9 abilities, these give an agent everything it needs to understand a site before taking action. All are read-only, require existing capability checks, and expose no personal user data. An open question is whether these should ship as three separate abilities or consolidate into a single core/get-site-orientation that returns theme, plugins, and health in one call — reducing the always-loaded tool count for agents.
WP AI Client
The server-side WP AI Client ships with WordPress 7.0, providing the PHP foundation for AI provider integration. The open question is about the next two layers landing in WordPress core:
- Trac #64872 Add AI REST API Endpoints (
wp-ai/v1): exposes the AI client functionality through REST, enabling any authenticated consumer (Gutenberg, mobile apps, external tools) to make AI requests through the site’s configured providers. - Trac #64873 Add JavaScript client (
wp-ai-client): the@wordpress/aipackage that gives block editor and admin JS a standardized interface for AI operations, built on top of the REST endpoints.
PR #10915 bundled both layers but did not land in 7.0. The open question is whether this is still worth championing. If yes, the merge strategy needs a decision: land these as separate PRs into core, or merge into the AI plugin first with feature detection as an interim step. I’d like to see contributors align on direction before 7.1 feature freeze.
Active research — future considerations
Content management abilities
Prior explorations in wordpress-develop#10665 and wordpress-develop#10867 started work on content-oriented abilities. The direction is to introduce CRUD operations consolidated by shared data model — post_type as a parameter rather than a separate ability per type — with content types opting in. This follows the consolidation patterns that keep the tool count manageable as the ecosystem grows.
Generic post type management covers the basics and is a must-have. But many custom post types have specialized functionality beyond basic CRUD — plugin creators should build dedicated abilities for those. The generic ability should signal this clearly: general-purpose post type management, use the dedicated ability if one exists for your content type.
Agentic loop support — Trac #64865
Add agentic loop support for auto-resolving abilities to the WP AI Client. This would let WordPress run multi-step AI workflows where the model discovers available abilities, calls them as tools, and feeds results back. The PHP AI Client already has the foundation, and this ticket tracks closing the gap so WordPress can orchestrate agentic workflows natively.
JSON Schema normalization — Trac #64955
A wp_compile_ability_schema_for_ai() function to transform canonical WordPress draft-04 schemas into AI-provider-compatible variants at output boundaries. A full audit of all 37 draft-04 keywords against WordPress’s implementation identified three critical gaps: $ref/definitions support (no schema reuse today), type juggling (WordPress’s validator is strictly more permissive than draft-04), and required v3 syntax still predominant in core schemas.
The ticket is filed with a research comment. A wp_rest_allowed_schema_keywords filter is part of the proposal. This is long-term. The schema surface works today for the current ability count, but will become a bottleneck as the ability surface grows and external tools (MCP clients, OpenAPI codegen, TypeScript extractors) consume WordPress schemas directly.
WebMCP — WordPress/ai#448
WebMCP is MCP-inspired but not MCP. The browser mediates everything and there’s no JSON-RPC. The spec is a Draft Community Group Report, not on the Standards Track, and the API surface is actively breaking. Browser support is limited to a Chrome DevTrial explicitly framed as a prototype, not an intent to ship. Firefox and Safari have no signal.
What matters for planning: the Abilities API’s shape (name + description + JSON Schema + implementation) maps cleanly to both WebMCP’s ModelContextTool and MCP’s tool definitions, so it can feed both transports without changes. A draft adapter experiment exists in WordPress/ai#224. We can adopt incrementally via polyfill, but should avoid building against API surface that’s still breaking.
Get involved
This is one person’s read on priorities. The actual ordering depends on contributor bandwidth, which champions step up, and where the AI plugin‘s real-world usage exposes friction next. I’d genuinely like to hear what others think — what you’re most excited to see ship in WordPress 7.1, and where you think this is wildly mis-prioritized. The conversation is happening on the Make Core AI blog and in #core-ai on the Make WordPress Slack (signup at make.wordpress.org/chat), and all of the linked tickets and issues above are open for feedback.
Leave a Reply