Abilities API: proposal for read-only navigation menu abilities (core/list-nav-menus, core/get-nav-menu)

[builder106]

An end-to-end agent session against a live WordPress site (Astra child theme, MCP server driving abilities-api) surfaced a gap: there's no way for an agent to list, inspect, or otherwise reason about the site's navigation menus. wp_get_nav_menus(), wp_get_nav_menu_items(), get_registered_nav_menus(), and get_nav_menu_locations() are all stable core functions, but none of them are exposed through the Abilities API. Full details and the manual-work-cost ranking are in ​WordPress/mcp-adapter#181.

Proposal

Two read-only abilities:

• core/list-nav-menus: wraps wp_get_nav_menus(), get_registered_nav_menus(), and get_nav_menu_locations().
• core/get-nav-menu({ id }): wraps wp_get_nav_menu_items() for a given menu.

Both are read-only and idempotent, with no destructive side effects. A working proof of concept is drafted and tested on a fork: ​fork diff.

Open questions

• Category: should these live under navigation, or under the existing site category alongside core/get-site-info?
• Is the readonly: true, destructive: false, idempotent: true meta annotation the right shape for abilities like this?

Next steps

Per justlevine's guidance in #core-ai, the plan is to land this in WordPress/ai for review and real-usage feedback before proposing a merge into core. This ticket is the first step; a WordPress/ai PR and eventual merge proposal will follow.

[gziolo]

I can see a PR open for the AI plugin: ​https://github.com/WordPress/ai/pull/858. It proposes a single core/read-nav-menus which aligns with the patterns promoted by @jorgefilipecosta in ​Merge Proposal: Expanding WordPress Core Abilities. Let's follow the same workflow: review the PR for the AI plugin and test it with users before submitting it to WordPress Core.