Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds real information beyond the annotations: an approval gate in Royally for any non-read-only ability, and that the change is recorded but cannot be reversed. This elaborates on destructiveHint rather than contradicting it. Return shape and latency of approval are still unstated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose first, then the approval semantics, then the irreversibility warning — well ordered. The closing sentence partly repeats the destructive hint, but every sentence still carries usable signal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an untyped generic dispatcher with no output schema, the description covers the essential operational facts: it can run anything, some calls block on human approval, and results are not reversible. The one meaningful omission is guidance on discovering available ability names and their parameter shapes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so ability_name, parameters and site_id are already documented. The description only restates that parameters are passed through, without clarifying that the keys inside 'parameters' are ability-specific or where to find the abilities' own schemas — baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (execute a registered WordPress ability) and identifies itself as the generic execution layer that can run any ability. The distinction from discover-abilities / get-ability-info is only implied via 'registered ability', not named, so it falls short of the 5 bar.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage context (read-only abilities run immediately, others require approval) but never says to call discover-abilities first to obtain a valid ability_name, nor names any exclusion or alternative execution paths such as the many royal-mcp__* wrappers in the sibling list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.