Core Abilities gain read-only settings, content, and users in 7.1

This proposal expands the WordPress Core Abilities API in WordPress 7.1 with three read-only abilities:

• core/read-settings
• core/read-content
• core/read-users

The Abilities API shipped in WordPress 6.9 as a foundation for registering discrete, permission-checked actions with typed input and output schemas.

WordPress 6.9 included only a small initial set of Core abilities, including site, environment, and current-user information. Since then, we have been experimenting with PRs in the AI plugin and WordPress Core. The next useful step is a small, read-only expansion that lets agents and workflows understand the key data already managed by a WordPress site: settings, content, and users.

Purpose and goals

The goals for this proposal are:

• Ship a canonical baseline of read abilities for WordPress’s Core entities, so the ecosystem builds on them instead of re-implementing them.
• Make a standard WordPress install meaningfully agent-readable: an agent can retrieve and understand a site’s configuration, content, and users.
• Give the AI Client (merged in 7.0) something real to call as “tools”. For example, allow someone to execute this prompt: “Propose a draft titled “June 2026 Summary” summarizing all the posts I wrote in June 2026 linking to the original posts.”
• Have abilities that expose content so that, once WebMCP (or similar technology) is stabilized, we can allow agents to consume it by simply mapping abilities to tools.
• Establish a repeatable pattern for future abilities covering comments, themes, plugins, taxonomies, media, and other Core entities.

Ability shape

The long-term direction is to organize Core abilities mostly in pairs:

• A read ability, such as core/read-content, that retrieves a single item or a collection.
• A manage ability, such as core/manage-content, that updates data or performs a user-intent action.

Settings and post types will use a show_in_abilities flag so that registering something in WordPress does not automatically make it available to ability consumers. In the future, that flag could be used for post meta or user meta. Core will opt into a conservative default set of built-in settings and post types, similar in spirit to how show_in_rest made selected entities available to the REST API.

Proposed 7.1 scope

core/read-settings

Returns settings that have explicitly opted in to abilities. It returns a flat name => value object and supports filtering by group or by specific setting names. It requires the manage_options capability.

This lets authorized tools answer questions such as “what is the site title?” or “which permalink-related settings are exposed?”

Relevant work:

• WordPress/ai#691, (just a rename WordPress/ai#806)
• wordpress-develop#12141, wordpress-develop#10747 earlier approach, closed
• Trac #64605

core/read-content

Retrieves content from post types exposed to abilities. It supports single-item lookup and collection queries. The default response is lean, while more expensive or sensitive fields are returned when explicitly requested.

Relevant work:

• WordPress/ai#739
• wordpress-develop#12195
• Earlier exploration of advanced content queries: wordpress-develop#10665 closed, not for 7.1
• Trac #64606

Advanced query support, such as meta_query, tax_query, and date_query, is intentionally left for a future version. Those shapes may be valuable for agents and workflows, where a slower targeted query can be better than retrieving everything and filtering client-side, but they need a focused review.

core/read-users

Retrieves users through single-user lookup or collection mode. It supports lookup by fields such as ID, email, login, or nicename, and collection filters such as roles, published-post status, etc.

Users should only see data they are already allowed to see; inaccessible fields are omitted per user.

Relevant work:

• WordPress/ai#774
• wordpress-develop#10775
• Trac #64657

Why this belongs in Core

The WP AI Client and other agentic integrations like mcp-adapter need abilities as the tools they can pass to agents and prompts. Without Core read abilities, those integrations can call a model but cannot reliably answer basic questions such as what posts exist or which page is the front page.

The ecosystem is already experimenting with its own versions of these abilities. For example, right now there are multiple projects implementing the ability to retrieve a post. That is healthy exploration, but the common entities should converge on shared Core contracts. A Core-provided base reduces repeated work and gives the community one place to review exposure, capabilities, schema shape, and edge cases.

Abilities can present a shape that is natural to humans and models. The planned core/manage-content, for instance, could have an action property (publish, move-to-trash, …), so an agent asks for the same intent a human expresses by clicking a button, rather than having to know that “publish” means mutating post_status.

Abilities operate under different constraints than REST. In terms of what is available, we may have information (e.g., secrets) exposed via REST that is not exposed under abilities. And because abilities are invoked by agents and workflows rather than from a latency-sensitive front end, they can reasonably afford operations REST avoids. We keep advanced querying (e.g., meta_query) out of REST because it can be slow, but for an agent, a server-side meta query is still far cheaper than fetching everything and filtering client-side. This different latency budget is part of why a separate, abilities-shaped surface is worthwhile.

As WebMCP-style tool discovery and browser-accessible tool surfaces continue to evolve, having carefully reviewed Core abilities gives WordPress a path to becoming agent-ready as soon as WebMCP stabilizes. The same Core ability contracts can be mapped to WebMCP tools, so we can easily make WordPress agent-ready and expose its content in the format WebMCP accepts.

Security and privacy

The proposed abilities are read-only and carry read-only annotations. They perform full permission checks before execution.

The security model is:

• Settings and post types must opt in through show_in_abilities. This makes it possible to control what is visible to an agent. For example, a secret may be available over REST so the UI can manipulate it, but it should never be shown to an agent.
• Every ability includes a permission callback that checks the current user’s existing roles and capabilities (e.g., manage_options, list_users, etc.) to determine whether the ability can be executed.
• Sensitive fields are omitted unless the current user has the required capability.
• Prompt-injection protection for ability results is out of scope. Abilities return stored data as-is. Agents and models that consume those results must treat them as tool output, not instructions to follow.

Goals for 7.2 and beyond

After the read abilities settle, the next layer is management abilities:

• core/manage-settings
• core/manage-content
• core/manage-users

Future content work may also revisit advanced querying, including meta_query, tax_query, and date_query, building on the earlier exploration in wordpress-develop#10665.

We also plan to support more entities, specifically comments, taxonomies, media, themes, and plugins, following the same read/manage + opt-in pattern, with extra guardrails for higher-risk operations.

Feedback

Feedback is welcome in the comments on this proposal, on the linked AI PRs, and in the #core-ai channel on WordPress Slack. If you maintain or are building abilities for these entities, we would especially like you to test the implementations and tell us if the shape, defaults, or permissions fit your use case. The goal is one baseline the whole ecosystem can build on.