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

Annotations already declare readOnly=true, idempotent=true, destructive=false and closed-world, so the safety profile is covered. The description adds behavioral value by sketching the content of the returned playbook without an output schema, and by signalling that applicability is scoped to UK firms of a given sector.

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?

Front-loaded with the purpose, then the trigger list, then the fallback in a short second sentence. Slightly redundant because the sector enumeration appears both in the description and the required enum, which is the only thing keeping it from a 5.

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 read-only, closed-world lookup with a fully documented single enum and no output schema, the description is complete enough: an agent knows what the tool returns and when to call it. It could add a hint about output depth or length, but nothing needed to invoke it correctly is missing.

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?

The single sector parameter is documented at 100% schema coverage, including the enum and per-value definitions, so the baseline is 3. The description restates the sector list in prose (accountancy, recruitment, law, insurance broking, property, construction, trades) but adds no mapping or nuance beyond what the enum description already supplies.

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 description opens with a concrete verb + resource ('Describes how a specific type of UK firm uses AI') and then enumerates exactly what the output covers (what gets drafted, chased or checked, what to look for in a tool, questions firms ask). It is instantly distinguishable from the siblings, which are all action/evaluation tools (assess, check, draft, estimate) rather than a reference lookup.

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 gives explicit trigger conditions by naming the roles and sectors that should call it (accountancy, recruitment, law firm, financial planning, insurance broking, estate/letting, construction, trades) and closes the loop with 'Use other for any other small business.' It stops short of routing to a sibling tool for out-of-scope callers, so it is clear context rather than full when/when-not/alternative guidance.

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