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

Annotations already mark the tool read-only and idempotent, and the description adds substantial behavioral context: internal cascade across lookup endpoints, explicit `unresolved` reporting, graceful degradation of LEI/FIGI enrichment, and `figi_candidates` when a name matches multiple instruments. This goes far beyond the annotations and tells the agent exactly what to expect.

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 and dense, but nearly every clause adds necessary behavioral or input detail for a tool with no output schema. It is front-loaded with purpose and usage guidance; the heavy parenthetical chains reduce scannability slightly, preventing a perfect score.

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 the tool's complexity, two required parameters, and no output schema, the description covers supported entity types, input formats, ambiguity handling, fallback behavior, and return values like `unresolved` and `figi_candidates`. An agent has enough information to invoke the tool correctly and interpret its results.

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?

Although the schema already documents both parameters at high coverage, the description adds critical practical guidance: exact accepted forms for company names, tickers, CIKs, ISINs, and drug names, plus the anti-example that users should pass the issuer name only and never the full noun phrase. This transforms the parameter schema into actionable invocation rules.

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: it resolves a user-spoken NAME to canonical/official identifiers, with concrete examples like ticker, CIK, LEI, and RxCUI. It clearly separates this from siblings by noting the resolved identifiers are what 'other tools require as input' and instructs 'Use FIRST whenever you have a name but need an ID.'

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 strong when-to-use guidance: 'Use FIRST whenever you have a name but need an ID,' plus example questions such as 'find the CIK for…'. It does not explicitly name alternative sibling tools or state when not to use it, but the directive is clear and contextually adequate.

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