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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description then adds behavior the annotations cannot: the exact boolean logic that decides a pass, the caveat that margin improvement is "checked only where both margins exist," the sparsity behavior of max_marketcap, and the returned ``coverage`` field that admits data gaps. This tells an agent how to interpret empty or partial result sets, which is the highest-value disclosure for a screening tool.

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 and pattern logic before an explicit Args block and a Returns line, so an agent can stop reading early and still call it correctly. It is somewhat long and the render_chart instruction is operational boilerplate rather than tool semantics, but almost every sentence carries distinct information.

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 nine-parameter screening tool with no schema descriptions, the definition supplies purpose, per-pattern algorithms, parameter semantics, silent-failure cases, and result shape (quality_metrics fields, turnaround row fields, rules thresholds). With an output schema present it need not enumerate return types, and its brief Returns paragraph is a bonus that costs nothing.

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 0%, so the description carries the full burden, and it does: every one of the nine parameters is documented with defaults, accepted values (country codes including aliases, stage values, industry examples), and units (percentage CAGR, native currency, EUR revenue floor). It also flags the non-obvious interaction where max_marketcap is silently inert outside Nordic/global scoping, which the bare schema could never convey.

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?

Opens with a specific verb and resource ("multi-year pattern screens over reported annual figures") and immediately scopes it against alternatives by saying it is "equivalent to several screen_companies calls intersected." The two named patterns (quality_growth, turnaround) each get a precise pass condition, so an agent can tell exactly what universe of companies comes back.

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 per-pattern selection criteria, states which parameters are "turnaround only" and that others are ignored in that mode, and routes the agent to a next step ("to confirm a candidate, check search_filing_content for restructuring language"). It also supplies a hard exclusion for max_marketcap ("on a US or unscoped screen it returns no companies") and warns results are "not a recommendation," which is unusually complete when-to-use guidance.

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