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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the result 'carries the inner tool's freshness and cite,' and several families are flagged as 'committed data verified against the banks' own pages' or 'verified against gov.uk,' which tells the agent about data provenance and trustworthiness.

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 purpose and the key caveat are correctly front-loaded in the first clause, but the body is a long unstructured run-on enumeration mixing tool names, parameter snippets, supported countries, and provenance notes. For a dispatcher the list has value, yet it is far from tight and buries useful groupings in a wall of text.

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?

There is no output schema, and the description compensates partially by stating the result carries the inner tool's freshness and cite, and by pointing to the catalogue for per-tool schemas. It does not explain how nested 'arguments' should be shaped or what happens for an invalid tool name, which keeps it short of fully complete for a 2-param dispatcher with a nested object.

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 the baseline is 3, and the description goes further by effectively enumerating valid values for the required 'tool' parameter (the long-tail names, the support_status/support_timeline products, the calendar_facts kinds, etc.), which the schema's generic 'tool name from catalogue' does not. It still defers argument schemas to the catalogue rather than describing them here.

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?

The opening clause 'Run any Data Butler tool by name' gives a specific verb (run) plus resource (any Data Butler tool) and immediately distinguishes this dispatcher from the sibling 'catalogue' by framing itself as the execution path for 'the long tail not listed here.' It even names which siblings are listed directly (uk_rates_lookup, domain_provenance, package_provenance, take_home_pay), so an agent can separate them without opening either schema.

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?

It clearly scopes usage to tools 'not listed here' and explicitly notes the four tools that are listed directly, which implies those should be called on their own rather than through this dispatcher. What is missing is an explicit 'do not use this for X' statement or error-handling guidance for an unknown tool name, so the routing is strong but inferred rather than stated.

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