New WordPress Abilities can make functions discoverable to REST, MCP and AI integrations. Before rollout, website owners need a clear decision about what may be visible, who may execute it and who is accountable for its business purpose.
A visible capability is not the same as an authorised action. This distinction matters when WordPress describes functions not only inside the dashboard but also to external systems and AI enabled workflows. Without an inventory and clear ownership, a small technical setting can expose unexpected data or actions.
Which website capabilities should you inventory first?
Start with custom plugins, bespoke integrations and every function that reads, changes or exports data. For each Ability, record its purpose, the affected data and the systems that can discover or call it. Include older REST endpoints and automations so that no parallel access layer is missed.
The inventory should make business impact visible. A simple status query needs a different review from a function that transfers customer data or publishes content. This creates an order based on impact rather than technical complexity alone.
What should readers, systems and AI services actually see?
WordPress 7.1 introduces a shared public metadata flag for Abilities that can govern public discoverability. Channel specific settings can take precedence, so reviewing only the general flag is not enough. Document for REST, MCP and other adapters whether and why each function should be visible.
Less visibility makes sense when a function is needed only internally or offers no value to external consumers. Public description can be useful when a controlled integration route is explicitly intended. The decision should follow the business purpose, not a convenient default setting.
How do you separate discoverability from real permission?
The public flag does not replace authorisation. For every executable function, review its permission_callback, the roles involved and the smallest necessary data scope. Also test accepted and rejected calls with realistic user accounts on a test instance.
Record which identity an external system uses and how its rights can be revoked. Logs should show who called each Ability, when they called it and what result followed. This traceability shortens diagnosis and supports controlled approval.
Who decides approval, oversight and the route back?
Every relevant Ability needs a technical owner and a person accountable for its business purpose. Together they confirm purpose, visibility, permission, data scope and logging before rollout. If any decision is missing, keep the function internal or disabled until it is resolved.
Define a route back for faulty or unexpected use. This includes disabling exposure, revoking credentials and testing a rollback of the affected integration. WordPress advises against testing the release candidate on business critical production systems.
DKSIGN can review Abilities, REST access, MCP adapters, roles and technical ownership as one operational inventory. The result is a prioritised list with approval decisions, owners and routes back. This keeps new integrations controllable for leadership, marketing and technical teams.
Checklist
- Inventory custom Abilities, REST endpoints and external integrations.
- Document visibility for each channel and its business purpose.
- Test permissions, roles and the minimum data scope in practice.
- Assign logging plus technical and business owners.
- Test disabling, credential revocation and rollback before rollout.
Do you know which WordPress capabilities are externally visible and who can execute them? DKSIGN reviews integrations, roles, logging and routes back as a controlled operational inventory.