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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering safety. The description adds useful context (Premium API, use cases) but does not disclose potential behavioral traits like rate limits, required authentication, or error handling. Since annotations carry the safety profile, the description adds modest value without contradiction.

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 two sentences, front-loading the core functionality and output fields, then adding use cases and pricing tier. It is efficient with no filler, though slightly dense. It earns a 4 for being well-structured and informative without unnecessary verbosity.

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 single-parameter tool with no output schema, the description fully compensates by listing all returned fields and specifying input flexibility (typos, local languages, tickers). It also gives practical context (use cases) and notes the premium nature. Everything an agent needs to decide and call the tool correctly is present.

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 input schema fully describes the single parameter 'lookup' with examples and a description. The tool description essentially repeats the schema's parameter description (organization name in any form) without adding new semantic detail. With 100% schema coverage, the baseline is 3, and the description does not exceed it.

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 clearly states the tool resolves any organization name to its official English legal name and lists a comprehensive set of output attributes (commercial name, legal form, country, registry ID, status, documentation URL). It also names concrete use cases (KYB, supplier verification, sanctions screening, dataset normalization), making it distinct from sibling tools like org_standard or company_verification by focusing on the 'official' name resolution.

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 description provides explicit intended use cases (KYB, supplier verification, etc.), giving clear context for when to use it. However, it does not explicitly compare to alternatives or state when not to use it, leaving some ambiguity relative to sibling tools that also handle organization names. It does mention it's a 'Premium API', hinting at cost but not contrasting with free alternatives.

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