WordPress’s push toward AI-ready infrastructure includes a merge proposal targeting version 7.1, which would add three read-only abilities to the Abilities API first introduced in WordPress 6.9. The API provides a structured, permission-checked way for external tools, AI agents, and automated workflows to interact with WordPress data using typed inputs and outputs — think of it as a purpose-built surface for machine consumption, distinct from the REST API.
The three abilities proposed for 7.1 are core/read-settings, core/read-content, and core/read-users. Each is scoped to read-only operations and enforces WordPress’s existing capability system before executing — core/read-settings, for example, requires the manage_options capability, while core/read-users omits fields the current user lacks permission to see. The proposal is backed by active pull requests in both the WordPress/ai and wordpress-develop repositories.
The WP AI Client, merged in WordPress 7.0, needs callable tools to do useful work. Without read abilities in Core, an AI agent connected to a WordPress site cannot reliably answer basic questions like what posts exist or which page is set as the front page. The proposal gives these agents a canonical, reviewed data surface rather than leaving the ecosystem to build competing implementations. It notes that multiple projects are already independently implementing the ability to retrieve a post — useful experimentation, but something that benefits from convergence. Each of the three new abilities serves a distinct purpose:
core/read-settings- Returns a flat name-to-value object of settings that have explicitly opted in via a
show_in_abilitiesflag, supporting filtering by group or specific setting name. core/read-content- Retrieves posts and other content from opt-in post types, supporting both single-item lookup and collection queries; advanced filters like
meta_queryare deferred to a future version. core/read-users- Looks up individual users or collections by ID, email, login, or nicename, with role and published-post filters available; inaccessible fields are silently omitted per user.
This opt-in model mirrors how show_in_rest selectively exposed data to the REST API. Settings and post types must explicitly set show_in_abilities to become visible to ability consumers — meaning a value exposed over REST for UI purposes can, if merged as proposed, be kept out of agent reach entirely. Prompt-injection protection is explicitly out of scope: abilities return stored data as-is, and consuming agents are expected to treat results as tool output rather than instructions.
The longer-term roadmap, if merged as proposed, pairs each read ability with a corresponding manage ability. WordPress 7.2 is the target for core/manage-settings, core/manage-content, and core/manage-users, with coverage of comments, taxonomies, media, themes, and plugins planned to follow the same read-and-manage pattern. The proposal also eyes WebMCP, an emerging standard for browser-accessible tool discovery, noting that Core ability contracts could map directly to WebMCP tools once that standard stabilises — giving WordPress a clear path to broader agent compatibility without additional architectural work.
