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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them by disclosing counting methodology that materially affects interpretation: sub-$0.10 conversions under 2% of last price are discarded as misread rates, implausible amounts are dropped, generic underwriter names removed, $10 blank-check IPOs and warrant/unit lines excluded from lock-ups. It also flags coverage limits ('roughly 900 filers a year, mostly small caps — none on record does not mean none filed') and that sectors are SIC-based and market cap approximate, which prevents false-negative conclusions.

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 front-loaded with purpose, then outputs, then filters, then caveats and routing — a sensible order. The KPI enumeration and the 'Rules' run are dense and could be tightened, but nearly every clause carries decision-relevant information rather than filler.

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?

With no output schema, the description carries the burden of describing returns and does so concretely: per-KPI lists, an underwriter league table with deals, lead deals and credited dollars, and a by-sector rollup, plus the limit default semantics in the schema. For a five-parameter, zero-required, read-only analytics tool this is complete enough to call 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 80%, so the schema already documents q, sector, under_2b, and limit. The description restates the accepted sector formats (SIC description or 2-digit SIC) and the under_2b threshold, which mirrors the schema rather than extending it, and it never mentions the limit parameter. Baseline 3 applies.

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 the specific resource (market-wide ECM activity and dilution for listed US companies), the time-window dimension, and enumerates the exact KPI families returned: offerings, ATM programmes, resale registrations, reverse splits, authorized-share increases, variable-price converts, lock-ups, plus league table and sector rollup. It explicitly distinguishes itself from the single-company sibling by closing with 'For one company use company_dilution.'

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?

It gives clear routing guidance by naming company_dilution as the alternative for single-company queries and frames itself as the market-wide scan, and the filter list implies the narrowing strategy (sector, under_2b, q). It stops short of stating when-not to use it (e.g., versus sector_monitor) or how to choose among the four windows beyond listing them.

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