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

Annotations already cover read-only, open-world, and non-destructive, but the description adds traits they cannot: results are capped at five, the data is third-party market data rather than the user's, and an empty list means "no wins data available" rather than "wallet never won." That last point materially changes how an agent reports the outcome.

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?

The core facts are front-loaded and useful, but the same warning is restated three times — "not the user's," "NOT about the user's own wallet," and "tools whose names start with get_my_ are the user's." Two of those sentences could be merged without losing information, and the repetition crowds out the undocumented `network` parameter.

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 no explanation, and the description covers scope, cap, empty-result semantics, and data ownership. The only real gap is the unexplained `network` parameter, which is minor given it is a constant/optional field defaulting to solana.

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 50%: `wallet_address` is documented (including that opaque references work) and the description reinforces "one TRACKED WHALE wallet," narrowing the acceptable input source. However, the `network` parameter is never addressed and the description adds no syntax or sourcing detail beyond the schema, so the baseline 3 fits.

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?

"The biggest realised wins of one TRACKED WHALE wallet — its top closed trades by profit, at most five" names a specific verb (rank by realised profit), a specific resource (closed trades of a single wallet), and a hard cap. It is clearly distinguishable from siblings like get_whale_wallet_track_record or get_whale_wallet_positions without opening either 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?

It states the use case explicitly — judge whether a wallet seen in a WhaleWatch feed is good before weighting its activity — and names the alternative for the adjacent need (`get_my_closed_positions` for the user's own realised results). It also states the empty-list interpretation rule so the agent does not misread a no-data result as a negative verdict.

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