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

The annotation already declares readOnlyHint=true, so the tool is safe for reads. The description goes further: it discloses that the tool does not invent numbers, that it returns SAFE_REFUSAL instead of hallucinating, and that monetary answers use the filer's default currency unless FX conversion is requested. This fully documents the honest-failure behavior and currency default, which is critical guidance beyond the annotation.

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 highly efficient: three sentences, each with a distinct purpose. No fluff. It front-loads the core purpose, then adds the critical SAFE_REFUSAL nuance, then the currency defaults. Every sentence earns its place, and the total length is appropriate for the complexity (4 parameters, nuanced behavior).

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 presence of an output schema (so return structure is documented), 4 parameters fully described, and strong annotations, the description covers everything an agent needs: purpose, refusal behavior, currency handling, and parameter semantics. There's no missing guidance for the complexity level.

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 description coverage is 100% and the description adds meaning: it explains the 'query' field should be natural language, optionally with 'in USD', and clarifies that 'target_currency' uses audited annual-average rates with provenance. The 'usd_only' boolean is also contextualized as forcing USD conversion. The description adds value by tying parameters to real-world behavior (FX conversion, provenance tracking) that the schema alone doesn't capture.

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 clearly states it queries Certified SEC facts, returns verified values with provenance or SAFE_REFUSAL, and explains how to handle that response (success-of-honesty). It is distinct from siblings like 'query_sec_metric_exact' or 'compute_sec_cagr' by emphasizing verified/provenance data and honest refusal.

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 tells the agent when to use this tool (for certified, provenance-backed answers) and provides corrective guidance: treating SAFE_REFUSAL as a success-of-honesty not a tool failure, and how to request FX conversion via parameters or natural language hints. This helps avoid confusion with sibling tools that might invent or compute values.

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