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

With no annotations present, the description carries the full burden and does so: 20s rewrite cadence, <=30s chain lag, a 120s staleness cutoff that returns 503 without charging, and a $0.02 USDC x402 payment requirement. These are exactly the operational facts an agent needs before calling, and none are available in structured fields.

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?

Four sentences, front-loaded with the definition and then the practical constraints; nothing is padding. The 'spot sniper crews before they dump' sentence duplicates ground covered by the usage framing, which is the only mild redundancy.

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 not be described, and the remaining agent-relevant facts — freshness guarantees, failure mode, and cost — are all stated. For a two-parameter read endpoint with a payment gate, nothing material 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 100%, so limit and minBursts are already fully documented with ranges and defaults. The description's 'bought inside 3 or more of the buyer bursts' loosely echoes minBursts' default but adds no syntax, unit, or interaction detail beyond the schema, so 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?

Names a specific resource (repeat-buyer clusters on Robinhood Chain) and defines the selection rule precisely: wallets that bought in 3+ captured buyer bursts, with burst count and last-seen time. This resolves the opaque name 'rh_crews' and distinguishes it from siblings like rh_bursts_live and rh_bursts_history, which report bursts rather than clustered wallets.

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 an intended use ('spot sniper crews before they dump on you'), which implies the detection scenario, but never contrasts this with rh_bursts_live / rh_bursts_history or states when this tool should be preferred over fetching raw burst data. Usage is implied rather than routed.

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