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

The description goes well beyond the annotations by disclosing key behaviors: ambiguous matches return figi_candidates rather than asserting a result, unresolved identifiers appear under `unresolved` rather than being omitted, identifiers are source-labelled, and LEI/FIGI enrichment degrades gracefully if upstream services are unavailable. This gives the agent a strong behavioral model of the tool beyond the read-only/idempotent hints.

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 information-dense and front-loads the core purpose and usage rule, but it becomes a long, sprawling paragraph with deeply nested parentheticals and a very long run-on sentence under 'company'. Most content earns its place, but the structure makes it harder to parse than necessary, so it is not concise enough for a 4.

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?

Given there is no output schema, the description compensates well by naming the returned identifiers (CIK, ticker, company_name, LEI, parent/ultimate-parent/children, FIGI, RxCUI, ingredient, brand), the `figi_candidates` and `unresolved` fields, source labelling, and graceful degradation. It covers ambiguous matches, unsupported cases, and service failures, making the tool sufficiently callable for an agent without additional context.

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 description coverage is 100%, so the baseline is 3 because the schema documents both parameters. The description adds real value by introducing ISIN as an accepted company input (not listed in the schema), explaining how ISINs map to legal entities, and clarifying type-specific return contents. This exceeds the schema's parameter descriptions without being redundant.

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 user-spoken names to canonical/official identifiers ('resolve a user-spoken NAME to the canonical/official identifiers other tools require as input') and gives concrete examples like ticker, CIK, LEI, and RxCUI. It is specific about verb, resource, and supported entity types, but it does not explicitly distinguish itself from sibling tools such as entity_profile or compare_entities, so it falls short of full sibling differentiation.

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 explicit guidance to 'Use FIRST whenever you have a name but need an ID' and provides detailed input-handling rules, including the important caution to pass only the entity name and not the full noun phrase. However, it does not explicitly state when not to use this tool or name alternatives, so it lacks full when-not/alternative coverage.

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