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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, and the description adds substantial behavioral context beyond those hints: it asserts nothing on ambiguous matches and returns figi_candidates; it places unresolvable identifiers under unresolved rather than omitting them; it degrades gracefully when GLEIF/OpenFIGI are down; and it reveals internal cascading through multiple endpoints. This goes far beyond what annotations alone communicate and never contradicts them.

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 content is front-loaded (purpose and 'Use FIRST' lead) and every sentence carries information, but the description is a single dense paragraph with deeply nested parenthetical blocks — the corporate-bond digression and the ISIN explanation are run-on walls of text that tax scanning. It earns its length for a tool this complex, but the structure sacrifices readability for comprehensiveness.

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 two-type tool with no output schema and multiple identifier sources, the description is unusually thorough: it names every identifier returned (CIK, ticker, LEI, FIGI, RxCUI), states how ambiguity resolves (figi_candidates), how unresolved identifiers surface (unresolved), and how failures degrade. The only gap is that no output envelope/JSON shape is specified, which matters more given the absence of an output schema, but the behavioral coverage is otherwise complete.

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% (both params described), so the baseline is 3, but the description adds real meaning beyond the enum and param comments — most notably the critical rule to pass the ENTITY NAME ONLY for bonds (never the full noun phrase) because 'trailing security-class words match nothing,' and the note that an ISIN resolves to the issuing legal entity. This meaningfully extends what the schema states, though the schema already handles the basic value formats.

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 states a specific action (resolve a user-spoken NAME to canonical/official identifiers) with a concrete resource (cross-source identity spine across SEC EDGAR, GLEIF, OpenFIGI, RxNorm) and enumerates six example query phrasings. It clearly distinguishes itself from siblings like entity_profile, compare_entities, and validate_claim by positioning itself as the identity-resolution prerequisite — an agent can pick it apart without opening any schema.

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 gives an explicit when-to-use directive: 'Use FIRST whenever you have a name but need an ID.' It also states that using it replaces 2-3 manual lookups, reinforcing the trigger condition. However, it names no sibling alternatives and provides no when-NOT-to-use exclusions (e.g., it never says to route to entity_profile for the reverse direction), so the guidance is clear on when but not on what to use instead.

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