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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, and the description layers substantial extra behavior on top: a 60-candidate window with at most 12 returned rows, presets that only become stricter, a custom baseline requiring >=300M market cap and valid canonical fair value, and an instruction to disclose incomplete results, source dates, missing coverage and negative-equity caveats. That is materially more than the annotations provide.

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 a clear 'Use this when...' trigger, and the sentences are dense but purposeful. It is long for a description, with some near-redundancy against the schema (e.g., 'Presets only become stricter' echoes the filter object's description), but nothing is padding.

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 need no explanation; within that constraint the description still covers the bounded result window, the baseline conditions, preset-vs-custom behavior, and disclosure caveats an agent must relay. Nothing needed to call it correctly 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?

Schema coverage is 60%, so the schema carries much of the per-filter burden, but the description adds real meaning: percentages are decimal fractions, the AND-conjunction only tightens a preset, and the custom baseline imposes implicit constraints (market cap floor, valid canonical fair value) that shape which filters are meaningful. It does not restate every filter, which is appropriate.

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 names a specific verb+resource (a bounded stock screen) and enumerates concrete use cases (undervalued, quality, dividend, large-cap, positive-FCF), so an agent immediately knows what the tool returns. It scopes the tool as a bounded candidate window rather than an exhaustive scan, but it never names or contrasts the adjacent siblings (search_securities, get_stock_fundamentals), so sibling differentiation is left to inference.

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?

Strong internal guidance: 'Use this when the user wants a bounded ... screen,' choose a preset or compose filters, use the smallest faithful filter set, and state chosen thresholds. It also gives explicit exclusions ('Arbitrary database queries and trade instructions are not supported'). The only gap is that it never says when to prefer this over search_securities or get_stock_valuation.

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