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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds significant behavioral context beyond that: it cascades through multiple lookup endpoints, enriches from GLEIF/OpenFIGI with graceful degradation when those sources are unavailable, returns ownership info, and explicitly reports unresolved identifiers under an 'unresolved' field rather than omitting them. This gives the agent accurate expectations for edge cases and failure modes.

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 densely packed with necessary detail; almost every sentence adds operational knowledge (supported types, source identifiers, degradation behavior, input caveats, internal cascade). It is front-loaded with the core purpose and common query examples. Some redundancy exists around the 'FIRST' usage hint and the enumeration of identifiers, but for a tool with this much domain complexity the length is justified.

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 must explain return values, and it does: it names the identifier fields per type, mentions the RxNorm citation, and explains how unresolved identifiers are surfaced. It also covers input edge cases (non-equity instruments, ISIN-to-LEI for non-US issuers) and degradation behavior. An agent has everything needed to call the tool correctly and interpret the result.

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, but the description substantially enriches both parameters. For 'type' it explains how company vs drug changes the lookup and return set. For 'value' it provides real examples (AAPL, CIK, ozempic), clarifies that bonds need the issuer name exactly as printed, and warns against including trailing security-class words. This goes well beyond the schema descriptions and materially improves correct parameter construction.

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 query examples and states plainly: 'resolve a user-spoken NAME to the canonical/official identifiers other tools require as input.' It specifies two supported types (company, drug), lists the exact identifiers returned (CIK, ticker, LEI, FIGI, RxCUI), and clearly distinguishes itself as the name-to-ID resolver, which no sibling tool claims. This is a specific verb+resource definition that an agent can act on immediately.

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: 'Use FIRST whenever you have a name but need an ID.' It further clarifies accepted input forms for both types and warns against passing full noun phrases. It does not name sibling alternatives or state when not to use it, but the 'always first' instruction plus the input constraints provide solid pragmatic direction.

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