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

Adds context the annotations cannot convey: read-only underlying tools execute immediately, while mutating tools are gated behind human approval in Royally. That human-in-the-loop detail is the most important behavioral fact for an agent. It does not contradict destructiveHint=true / readOnlyHint=false; it just leaves approval failure or rejection handling 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?

The core dispatch semantics are front-loaded in the first clause, with the compact-profile rationale right after. The trailing '(site: ...)' aside and the 'Through Royally' sentence feel appended rather than integrated, but no sentence is wasted.

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 a router with nested arguments, an output-free schema and no way to enumerate valid tool_name values, the description covers the essential semantics and the approval gate. It could still say that the return value mirrors the underlying tool's response, and point at discover_tools for valid tool_name values.

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% and the schema already explains tool_name ('exact tool name to invoke') and arguments ('same shape you'd pass in tools/call'), so the description is largely restating it. The site_id enum is only referenced obliquely via '(site: demo.royalplugins.com)'. Baseline 3 is appropriate when the schema does the work.

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 action + mechanism: a pass-through dispatcher that invokes the tool named in tool_name with arguments, semantically identical to tools/call. This clearly distinguishes it from the concrete sibling tools (wp_*, wc_*, sv_*) and from the discovery siblings discover_tools/get_tool_info.

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?

Gives an explicit use condition: the client only advertised routing tools via X-MCP-Profile: compact and still wants to invoke an underlying tool without renegotiating the profile. It also names the alternative (direct tools/call) as equivalent, so an agent knows when either path is acceptable.

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