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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the bar is lower. The description adds rich behavioral context: it discloses internal cascading lookups ('replaces 2-3 manual lookups'), graceful degradation when GLEIF/OpenFIGI are unavailable, explicit listing of unresolved identifiers, and the behavior of returning figi_candidates when ambiguity exists. It also explains that non-equity instruments (bonds) are covered, which is non-obvious. This goes well beyond what annotations provide.

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 long but well-structured: it leads with a purpose statement and directive, then enumerates supported types, then details edge cases and fallbacks. It uses quotes and examples to break up text. While it could be trimmed, the density of critical information (e.g., bond issuer name handling, unresolved identifiers) justifies the length. It's not bloated or repetitive.

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 two entity types and multiple identifier sources, the description covers every aspect an agent needs: input format, output expectations (including unresolved and candidates), failure modes, and even performance characteristics ('replaces 2-3 manual lookups'). There is no output schema, so the description carries the burden of describing return behavior, and it does so comprehensively.

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 parameters described). The description adds substantial nuance: for 'value', it explains exactly what to pass for company (ticker, CIK, or name) vs drug (brand or generic), and warns against including trailing security-class words for bonds. For 'type', it clarifies the meaning of each enum value and what identifiers are returned. The description complements the schema rather than repeating 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 opens with concrete example queries and states clearly: 'resolve a user-spoken NAME to the canonical/official identifiers other tools require as input.' It enumerates the exact identifier set (CIK, ticker, LEI, FIGI, RxCUI) and supported types (company, drug). The phrase 'Use FIRST whenever you have a name but need an ID' explicitly distinguishes it from sibling tools like entity_profile or compare_entities, making the purpose unmistakable.

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 gives a clear directive: 'Use FIRST whenever you have a name but need an ID.' It also explains when to avoid using it (e.g., when a name matches multiple instruments, it returns candidates rather than asserting). It provides detailed input instructions for each entity type, including a warning for bonds to pass only the issuer name, not the full noun phrase. This is explicit, actionable usage guidance.

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