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

With no annotations, the description carries the full burden and does so well: it discloses credit cost (€0.02 per company), the auth mechanism (API key via Authorization: Bearer), the upstream data sources and licenses (GLEIF CC0, Companies House OGL v3.0), local checksum validation, the 5-candidate cap with match scores, and explicit PII exclusions.

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 purpose and lookup modes, then returns, then provenance/cost, then per-parameter notes — a sensible ordering with little filler. The returns section is a dense run-on that duplicates what the output schema already provides, which slightly dilutes the otherwise tight structure.

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 paid, multi-mode, externally-sourced lookup with no annotations, the description covers everything an agent needs to invoke it correctly: modes, formats, cost, auth, data provenance, and PII boundaries. Return values need not be enumerated because an output schema exists, yet the summary provided is a bonus rather than a crutch.

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 0%, so the prose has to document all five parameters, and it does: 20-character LEI, name as an 'alternative to lei', ISO-2 country filter, UK number with example formats (00445790, SC123456), and include_parents scoped to LEI lookups only. The gap is that it never states that exactly one of lei/name/uk_number must be supplied, and it describes include_parents as 'true' while the schema types it as a string.

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 and resource ('Legal entity lookup for KYB and invoicing') and enumerates the three exact lookup keys (LEI, name+country, UK company number). It also scopes what is and is not returned ('No directors or personal data'), so an agent can tell instantly this is not a general company-profile or people-lookup tool.

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?

The three modes are laid out with their selecting conditions (LEI when you have one and want local checksum validation; name+country when you don't; UK number for Companies House records), which is real mode-selection guidance. It stops short of naming alternatives or exclusions among siblings such as vat_check or sanctions_screen, so an agent must still infer that KYB entity resolution is this tool's domain.

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