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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's 'Never fabricates' and 'honest not_found' statement add behavioral guarantees beyond the schema. It also discloses cost (free within quota, then $0.02/call) and latency (~800ms), which are not implied by annotations. It does not describe any error cases beyond not_found, but that's covered. Overall, it adds meaningful context without contradicting the annotations.

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 description is longer than typical but is well-structured with bullet-like sections (WHEN TO USE, WHEN NOT TO USE, COST, LATENCY) and example queries. It front-loads the core purpose and then adds usage context. Slight redundancy exists ('Free' appears twice), but it's not verbose enough to detract seriously. Every section adds value.

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?

With 3 parameters, no output schema, and no nested objects, the description must convey the return format and behavior. It does so by listing the returned fields, stating the not_found behavior with the queried sources, and covering cost and latency. It also anticipates edge cases (private companies, fraud detection) via the exclusions. Nothing an agent needs to call 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?

Schema coverage is 100%, but the description enhances each parameter: it explains 'name' works with a legal name, 'lei' is a 20-character identifier for a direct precise lookup, and 'country' narrows GLEIF results to a jurisdiction. The examples show how to combine name+country and name+LEI, giving agents concrete usage patterns that the schema alone lacks.

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 specific verb+resource: 'Free, live lookup of a company official registry record,' and enumerates exactly what it returns (legal name, LEI, status, jurisdiction, address, authority). It also differentiates itself from siblings by naming the data sources (GLEIF and SEC EDGAR) and clarifying it is a first-pass existence check, not a full KYC screen. Example queries further cement its purpose.

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?

Contains explicit WHEN TO USE and WHEN NOT TO USE sections. The WHEN TO USE states clear trigger conditions (contract signing, vendor qualification, counterparty validation, due diligence) and the accepted input forms (name+optional country, or LEI). The WHEN NOT TO USE section explicitly excludes private companies not in GLEIF/SEC and clarifies it is not a fraud-detection tool, steering agents away from misuse, even though it doesn't name a specific sibling alternative.

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