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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the description's job is to add behavioral context beyond safety. It does this extensively: it explains identifier source labeling, explicit `unresolved` reporting, `figi_candidates` on ambiguity, graceful degradation when LEI/FIGI enrichment fails, multi-endpoint cascading, and special ISIN-to-LEI resolution. Nothing contradicts the annotations.

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 examples and the key usage rule, but it is an extremely long single block of dense parenthetical prose. Much of the detail is valuable, but it would be easier for an agent to parse if separated into scannable sections for company behavior, drug behavior, ambiguity handling, and degradation. It is more dense than concise.

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?

There is no output schema, so the description carries the burden of explaining what the tool returns. It covers return types (CIK, ticker, company_name, LEI, FIGI, RxCUI), source provenance, unresolved identifier handling, ambiguous-match behavior, and failure degradation. For a two-parameter lookup tool with rich edge cases, this is as complete as an agent needs.

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%, so the baseline is 3 and the schema already documents `type` and `value` with examples. The description adds valuable operational semantics beyond the schema: the instruction to pass the entity name only, the warning about trailing security-class words for bonds, the accepted input forms, and the meaning of the supported enums. This justifies one point above baseline.

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 verb and resource: resolving a user-spoken name to canonical/official identifiers needed by other tools. It distinguishes the tool from siblings like entity_profile and compare_entities by framing it as the identity-lookup layer, and it enumerates supported entity types and identifier sources. The "Use FIRST" instruction further sharpens the purpose.

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," which gives clear invocation context. It also explains behavior on ambiguous matches and non-resolvable identifiers, but it does not name alternative tools or state when not to use it, so it falls just short of a full when/when-not/alternatives treatment.

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