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

Annotations already declare readOnly, openWorld, and non-destructive, so the safety bar is met structurally; the description adds that this is public whole-market data, not the user's own wallet or holdings, which is real routing context. It stops short of describing the picks summary contents or pagination, but the output schema covers returns.

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 purpose and the 'call this first' instruction are front-loaded, and the negative disambiguation sentences each prevent a distinct error. It runs a bit long on the get_my_ clarification, but nothing is filler.

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 explained, and annotations cover safety. What remains — role in the navigation flow, sibling routing, and the public-vs-personal data boundary — is fully stated.

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?

Only one parameter exists and the schema pins it to const 'solana' with a default, so no semantic elaboration is needed. The description never mentions the network argument, but that argument is self-documenting; the 0% coverage score is misleading here because the schema entry is a constant.

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 description gives a concrete picture of the resource — a shell with a manual picks strip plus one summary per curated list (whale groups, KOL groups, proven-trader cohorts) — and explicitly blocks two misreads by naming get_whalewatch_lists and the get_my_ family. An agent can distinguish it from 'discover_wallets_to_follow' and 'get_whalewatch_wallet_list_detail' without opening any 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 an explicit ordering rule ('Call this first to learn the valid slug values for get_whalewatch_wallet_list_detail') and names the alternative with the condition that rules it out ('NOT the same lists as get_whalewatch_lists … that one is for filtering get_whalewatch_feed'). It also rules out the user-scoped tools via the get_my_ convention.

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