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

Annotations indicate read-only, idempotent, and non-destructive behavior, but the description adds substantial behavioral detail: ambiguous matches return `figi_candidates`, unresolved identifiers appear under `unresolved`, enrichment degrades gracefully, and the tool cascades through multiple endpoints. It also describes how ISIN inputs resolve to legal entities via GLEIF. This far exceeds what annotations alone convey.

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 verbose, starting with a long list of example queries and then expanding into extensive detail about supported types and edge cases. While well-structured and informative, it could be tighter; some sentences are redundant or overly elaborate. It's not poorly structured, but it's 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?

The description covers return values (figi_candidates, unresolved field), error handling (graceful degradation), and the cascading behavior. It also explains the distinction between entity types and how to format input edges. For a tool with no output schema and significant complexity, this is as complete as an agent could need.

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%, with both parameters already described in detail (type enum, value formats and examples). The description adds value by mentioning ISIN as an accepted input for company type, which is not in the schema's value description, and by clarifying that for bonds the issuer name should be passed exactly. This goes beyond the schema, so a 4 is warranted.

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 explicitly states the tool resolves user-spoken names to canonical/official identifiers, listing specific identifier types (CIK, ticker, LEI, RxCUI, FIGI). It distinguishes itself from siblings by framing it as the prerequisite for other tools that require IDs, and mentions 'Use FIRST whenever you have a name but need an ID.' This is a specific verb+resource with clear 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 direct usage guidance with the phrase 'Use FIRST whenever you have a name but need an ID' and notes that it replaces 2-3 manual lookups. It provides context about when to use it (name-to-ID resolution) but does not explicitly state when NOT to use it or mention alternatives. Still, the guidance is clear and actionable, so a 4 is appropriate.

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