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

Beyond the read-only/idempotent/non-destructive annotations, the description discloses important runtime behaviors: graceful degradation when GLEIF/OpenFIGI is unavailable, ambiguity handling via figi_candidates, explicit unresolved identifiers rather than silent omission, source labelling for every identifier, and internal cascading through multiple lookup endpoints. This is unusually rich behavioral context.

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 front-loaded with a practical purpose statement and example phrasings, and the type-specific details are organized under clear labels. It is long and dense enough that some parenthetical explanations could be trimmed, but the complexity of the tool justifies most of the length.

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 no output schema, the description still explains what callers can expect: source-labelled identifiers, an unresolved list, figi_candidates on ambiguity, and degraded enrichment behavior. Combined with parameter-level instructions and annotations, there is no critical missing information an agent would need to call and interpret this tool correctly.

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 adds substantial meaning beyond the schema: accepted input forms (ticker, CIK, ISIN, name), the ISIN-to-LEI mapping behavior, the distinction between brand and generic drug names, and the crucial warning to pass only the entity name and not trailing security-class words. This materially improves correct invocation.

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 names a specific action—resolve a user-spoken name to canonical/official identifiers—and clearly delimits what it covers (company: CIK/ticker/LEI/FIGI; drug: RxCUI). It positions the tool as the prerequisite for other tools and differentiates it from siblings like entity_profile by focusing on name-to-ID resolution rather than profile lookup.

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 explicitly says 'Use FIRST whenever you have a name but need an ID,' giving clear selection guidance and even explaining that one call replaces 2-3 manual lookups. It does not, however, name specific alternatives or state when not to use the tool beyond the implicit name-to-ID condition, so it falls just short of a perfect exclusionary usage guide.

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