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

Despite annotations declaring readOnlyHint, openWorldHint, and idempotentHint, the description adds substantial behavioral context: it cascades through multiple endpoints internally, asserts nothing when multiple FIGI candidates exist, explicitly reports unresolved identifiers, degrades gracefully when external sources fail, and labels identifiers with their provenance. This goes far beyond what the annotations capture.

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 an extremely long and dense wall of text with no bullet points, headings, or clear hierarchical structure. While every sentence carries information, the lack of formatting and the sheer volume make it difficult to parse quickly. It is under-structured rather than concise, earning a low score on this dimension.

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?

For a complex tool with two entity types, multiple identifier sources, and fallback behaviors, the description covers all necessary runtime aspects: what is returned for each type, how to handle ambiguous matches, behavior on source failures, and the internal cascading mechanism. There is no output schema, so the description correctly takes responsibility for explaining return values and edge cases. Nothing critical is missing.

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?

The schema already covers both parameters at 100%, including format guidance for 'value'. The description supplements this by noting that 'value' can also accept an ISIN for company type (not mentioned in the schema) and clarifies the exact naming convention for bonds ('never the question's full noun phrase'), adding meaning beyond the schema. This justifies a rating above the baseline of 3.

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 states a specific verb ('resolve') and resource ('a user-spoken NAME to the canonical/official identifiers') and clearly distinguishes itself from sibling tools by positioning as a prerequisite for tools that require IDs. It provides multiple example queries that map directly to this tool, making its purpose unambiguous to an agent.

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 explicitly says 'Use FIRST whenever you have a name but need an ID' and gives numerous examples of when this applies, including detailed handling for companies, drugs, and bonds. However, it does not explicitly name alternative tools or state when NOT to use it (e.g., when an ID is already known). This is a minor omission given the clarity of the primary condition.

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