WordPress 7.2 lets an ability declare required_capabilities and lets clients request a capability-filtered list. That can reduce irrelevant tools shown to an agent. It does not replace a permission callback that decides whether the current user may access the specific post, order or other object supplied as input.
WordPress 7.2 Beta 2 was announced October 27. The procedures here are for development environments as of October 28, 2026, not a recommendation to deploy beta software to a live site.
Separate a general entitlement from an object decision
Imagine a support tool that reads a record. A general capability may allow the user to use that class of tool. A second decision must determine whether this particular record belongs to the permitted site or customer context. Giving the tool a capability list does not answer the second question.
The required-capabilities change describes an initial capability check followed by an optional input-aware permission callback. When both are present, both must pass. Keep your existing object rules unless you have demonstrated that the operation genuinely needs only the capability check.
Do not substitute administrator access just to remove a permission error. That makes the test less representative and can conceal a missing least-privilege design.
Test discovery and direct execution independently
Create synthetic identities with and without the chosen capability. Use a test ability that returns harmless fixture data and records whether its execution callback ran. Do not use a refund, user deletion or production export as the test operation.
Compare an ordinary ability listing with a listing that requests current_user_can filtering. Then attempt the same fixture through the normal execution path. Retain the user identity, requested object, response and whether the callback executed.
| Identity and input |
What must be proven |
| Missing capability |
Restricted execution does not occur |
| Capability present, unauthorized object |
Input-specific rule still rejects |
| Capability present, permitted object |
Expected harmless result is returned |
| Capability revoked after listing |
A stale client list cannot authorize execution |
Capability checks narrow access to a tool; an input-aware check still controls the requested object.
Do not confuse remaining list entries with a bypass
Abilities without declarative capabilities may remain discoverable because their authorization depends on input. Seeing one in a filtered list is not proof it can run. Conversely, a client hiding a button is not proof the server denies a direct call.
For each tool shown in an MCP or other agent client, record how the client builds its list and whether it refreshes after permissions change. Test server enforcement with the same identity. Never rely solely on client-side filtering to protect private data.
Use the existing public, REST and MCP boundary checklist to keep channel exposure separate from authority. This new declaration adds a useful gate; it does not erase differences between clients or credentials.
Review registration edge cases
Inspect whether required_capabilities is a top-level registration argument containing valid capability names. An empty list is not an implicit public permission policy. Review callbacks for validity and preserve any input schema required by the ability.
If an integration customizes the final permission-result filter, include it in the review. A later customization can affect the final decision, so testing only the first capability check is incomplete. Record the active plugin set when comparing results.
Keep logs small: test identity, capability decision, synthetic object ID and result code. Do not log application passwords, authorization headers or full private responses. Remove temporary instrumentation once the fixture is verified.
Release with a negative-test record
The strongest acceptance evidence includes rejected cases, not only a successful administrator call. Preserve the matrix with the exact beta build and repeat it against the release candidate or stable version you plan to ship. A beta test is not a permanent certification of a changing integration.
For a tool that lists correctly but exposes the wrong object, request a permission-boundary review. Describe the unauthorized case explicitly so the repair targets authorization instead of hiding a UI control.
Sources checked October 28, 2026. Synthetic fixtures and diagrams illustrate the proposed checks; they are not claims of customer testing.
When the boundary is correct but a custom content type is missing, follow the content-query diagnostic: WordPress 7.2 Content Query: Why an AI Tool Cannot Find a Custom Post Type.