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

With no annotations supplied, the description carries the full load and does well: it discloses the paid nature ('$0.02 USDC on Base via x402'), the pool-selection heuristic (deepest WPOL/USDC pools only), and the conditional inclusion of launch data. It does not state that the call is read-only/no side effects, but the tracking framing makes that implicit and the cost disclosure is the materially important behavioral fact.

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 long sentence, but it is front-loaded with the core purpose before enumerating return fields and cost, so an agent gets the gist immediately. The clause density is high and the launch-history tail could be trimmed without losing selection-relevant 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?

No output schema exists, so the description must describe returns and it does: USD size, side, wallet, transaction hash, buy/sell volume, net flow, top counterparties, plus launch risk/liquidity/deployer data. Gaps are minor: no mention of what is returned if no qualifying pools or trades exist, and no pagination or ordering statement beyond 'largest trades'.

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 100%, so the schema already explains token, minutes, minUsd and limit. The description adds contextual meaning for the window ('last N minutes') and the size filter ('largest trades'), but nothing per-parameter. It also does not flag the schema inconsistency where the minutes field is described as block-capped 'about 50 minutes on Arbitrum' in a Polygon-only tool.

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 verb-and-resource pair ('whale and large-trade tracker') plus the exact chain and asset class (ERC-20 on Polygon PoS), and scopes it to the token's deepest WPOL/USDC Uniswap v3 pools. This cleanly separates it from chain siblings like eth_large_trades/base_large_trades and from analytics siblings like polygon_token_snapshot.

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 context is unambiguous: this is for surfacing buy/sell activity above a USD threshold within a look-back window, and it notes the launch-history block is included only 'when we recorded it'. It never states when to prefer polygon_token_snapshot or polygon_new_pools instead, and gives no prerequisites beyond the token address.

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