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

Annotations already cover read-only, idempotent, open-world, non-destructive, so the safety bar is low; the description still adds real substance by disclosing that results are the *largest* filings (implicitly size-ranked), that a default minimum value threshold applies via minUsd, what a 'cluster buy' means (3+ insiders buying the same stock), and that returned fields include insider, role, shares, price and value. It omits pagination, result-cap behavior and freshness/latency, which keeps it below a 5.

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?

A single front-loaded sentence that leads with the resource and then enumerates scope, fields and cluster-buy semantics; there is little waste. The disclaimer 'Data, not investment advice' is defensible for a financial feed, but the sentence runs long and mixes return-field inventory with selection criteria, which slightly dilutes scanability.

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-value shape need not be explained, and annotations cover the safety profile; the description fills the remaining gap by defining selection criteria (largest, open-market, lookback, optional ticker, cluster definition). The one material gap is the absence of any contrast with list_insider_trades, which is exactly the ambiguity an agent would hit next.

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 nominally 100%, but the schema descriptions are bare ranges ('1 to 90', '1 to 100') that convey no meaning; the description compensates by establishing that 'days' is a lookback window over filings and that 'ticker' is an optional narrowing filter (without it: all stocks). It does not clarify units or interaction between limit and minUsd beyond what the schema states, so it improves on the baseline rather than fully covering it.

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?

Names a concrete resource and scope: the largest open-market insider purchases and sales across all U.S. stocks in a lookback window, optionally narrowed to one ticker, plus cluster-buy detection. That is far more specific than a restatement of the name. However, it never distinguishes itself from the sibling tool list_insider_trades, leaving the agent unable to choose between two near-identical insider-data tools from the description alone.

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?

Usage is only implied: the parenthetical '(or for one ticker)' tells the agent how to narrow the feed and 'in the last days' implies a recency-bounded use case. There is no explicit when-to-use/when-not guidance and no pointer to list_insider_trades or get_smart_money as alternatives. On a tool list containing a directly overlapping sibling, that omission costs it a point.

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