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

Annotations already cover the safety profile (readOnly, openWorld, non-idempotent), and the description adds substantial behavior beyond them: ~2-minute refresh cadence with `data_as_of`, the `min_trade_usd` exclusion, one-swap-counts-once accounting, overlapping wallet-type membership (a wallet on two lists counts in both), and `smart_money` being null when unknown.

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?

Front-loaded with the core claim and the differentiator, and the sentences are dense but purposeful. The long enumeration of every returned slice and field partly restates what the output schema already supplies, which costs some length without adding equivalent value.

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?

Given an output schema exists, the description need not document return shapes, yet it still defines the non-obvious ones (dump_sells = sold half or more of position, fresh_launch thresholds, net_flow_usd). Combined with cache freshness and aggregation rules, an agent has everything needed to call and interpret it 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?

There is effectively one parameter (`network`, a const with default 'solana'), so there is little to explain and the 4 baseline applies. The description instead clarifies a server-side filter (`min_trade_usd`) that never appears in the schema, which is genuinely additive even though it is not a parameter.

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 resource and scope: whole-market whale/KOL/smart-money buy/sell/dump aggregates across three windows, returned in one call. It explicitly separates itself from the token-level siblings ('before reading a single token') and from the feed-paging tool `get_whalewatch_feed_window`, so an agent can pick it without opening a schema.

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 the decision rule ('tell "whales are dumping everything" from "this one coin is weak"') and names the alternative it replaces ('instead of paging `get_whalewatch_feed_window`'). It also closes the common mis-route by stating this is NOT the user's wallet data and that `get_my_*` tools cover that.

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