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

With no annotations supplied, the description carries the full behavioral burden. It discloses the important default that omitting tx_type ranks purchases and sales together rather than excluding one side, which is real value. But it says nothing about the return shape (ranked tickers with accompanying counts?), whether results are paginated, or that this is a read-only aggregation, leaving meaningful disclosure gaps for an unannotated 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?

Three short sentences, front-loaded with the core operation, followed by the routing rule for tx_type. Every sentence carries information and nothing is redundant 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?

For a simple three-parameter read tool this covers the mechanics adequately, but with no annotations and no output schema the description should do more to describe what comes back (a ranked list, with counts, limited by 'limit'). An agent knows how to call it but not exactly what it will receive.

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 already 100%, so the baseline is 3. The description still adds meaning beyond the schema by clarifying that the omitted-tx_type case ranks buys and sells together — the schema only says 'Omit for all trades,' which is ambiguous — and by framing tx_type as selecting the most-bought vs most-sold ranking rather than a mere filter.

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 and resource: ranking tickers by count of congressional trades within a look-back window, with the CTA record scope named. The only gap is that it never contrasts itself with nearby siblings like get_top_traders or get_trades_by_ticker, so an agent must infer this is the aggregate-ranked view rather than the per-trade list.

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 guidance for choosing among the tx_type values (Purchase for most-bought, Sale for most-sold, omit for combined), which is genuinely useful. However, that is parameter-level guidance, not tool-level guidance: nothing says when to pick get_top_tickers over get_top_traders or get_trades_by_ticker, and no prerequisites or exclusions are stated.

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