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

Annotations only cover the safety profile (readOnly/idempotent/non-destructive/openWorld); the description adds the domain-critical behavior that figures arrive as unscaled digit strings that must be multiplied by a power of ten, and the rounding constraint that rules out citing 416,161 as $416.9B. Also discloses volume (~2,000 vs ~400) and the hl deep-link construction.

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?

Front-loaded with purpose then a concrete JSON entry example, then the scale rule, then filtering and linking. Slight redundancy between the opening line and 'Each entry is a number with its label', but no sentence is wasted given the 0% schema coverage.

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?

An output schema exists, so return values needn't be enumerated, yet the description still supplies the interpretive layer the output schema can't (units/power-of-ten scaling, column ordering). Combined with filtering and deep-link guidance, an agent has everything needed to call and use the result correctly.

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 0%, so the description carries the full burden and does so: cik/filename carry format examples, `near` is defined as case-insensitive substring on the label with realistic examples, and `limit` is given both range (1-2000) and default (300), matching the schema.

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?

States a specific verb+resource ('List the numbers a filing document actually states') and immediately characterizes the return unit as a labelled figure with digits stripped of formatting. That framing distinguishes it from list_filing_tables (tables) and search_document (text search) without needing either schema.

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?

Gives concrete operational guidance: use `near` for label filtering, filter mandatory for 10-Ks (~2,000 figures) but optional for press releases (~400), derive scale from label/table heading, assume current-period-first column order but confirm. It stops short of naming alternative tools (e.g. verify_figure) for the case where you already have a number and want to check it.

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