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

The annotations already mark the tool read-only, idempotent, open-world, and non-destructive, and there is no contradiction in the description. Beyond that, the description discloses substantive runtime behavior: internal cascading through multiple lookup endpoints, graceful degradation when GLEIF/OpenFIGI are unavailable, explicit `unresolved` output rather than omission, and source labeling of every identifier.

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 definition is long, but almost every sentence earns its place by conveying examples, fallback behavior, or input formatting rules. It is front-loaded with natural-language examples and the 'Use FIRST' directive. A small deduction is fair because the content runs together in one dense paragraph rather than being broken into scannable bullets or sections.

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 tool with no output schema that consults multiple external sources, the description covers input formats, identifier sources, ambiguity handling, unresolved results, and failure degradation. An agent has enough decision-relevant context to select and invoke the tool correctly without further digging into external documentation.

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% and both `type` and `value` already have descriptions, so a baseline of 3 is appropriate. The description adds real value by detailing value formatting for bonds ('ISSUER exactly as printed', never the full noun phrase), accepting ISINs for company lookup, and explaining type-specific outputs such as RxCUI, FIGI, and LEI.

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 centers on a specific action: resolving a user-spoken name to canonical/official identifiers, with two explicit supported entity types (company, drug) and concrete examples such as ticker, CIK, LEI, and RxCUI. It is not a tautology and clearly carves out a niche distinct from generic search, though it does not explicitly name or contrast sibling tools like `resolve` or `entity_profile`.

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 contains an explicit directive: 'Use FIRST whenever you have a name but need an ID,' which is strong when-to-use guidance. It also sets expectations for ambiguity via `figi_candidates` and for graceful degradation when enrichment sources are unavailable. However, it does not name alternative tools or state when not to use this tool, such as when an identifier is already known and entity details are needed.

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