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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so credit goes to the domain context the description adds: it explains the two licence-basis values, that issuer_file is matched against the issuer's own published file at checked_at, and that 'stated' means unmatched. That is real interpretive guidance an agent could not get from the schema, though missing-slug behaviour is 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?

Two sentences, front-loaded with what the tool returns, then the licence-basis semantics. The second sentence is dense but every clause earns its place by defining terms the agent must interpret correctly; the parenthetical could be tightened slightly.

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?

No output schema exists, so the description appropriately enumerates the return contents (details, licences, contact) and pre-explains the licence-basis fields an agent will encounter. Missing only error/not-found behaviour, which for a simple read tool is a minor gap.

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?

With 100% schema description coverage and a single required parameter whose provenance ('from find_businesses') is already documented, the schema carries the burden. The description adds nothing further about the slug format or validation, so the 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 concrete verb-resource pair: retrieves one business's details, licences, and contact info. The singular framing implicitly contrasts with the sibling find_businesses, and the slug parameter ('from find_businesses') reinforces the lookup relation, though the sibling is never named explicitly.

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?

Usage is implied rather than stated: the schema tells the agent the slug comes from find_businesses, so the call order is inferable. The description adds a genuine downstream instruction ('send the person to source_url' for 'stated' licences), but never says when to prefer this over other siblings or what to do if the slug is unknown.

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