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

With no annotations, the description carries the full burden and does substantial work: it discloses the $0.01 per-call price, the accepted payment rails (USDC on Arc/Base/Solana, XNT on X1), the hourly refresh cadence, the methodology (closed trades, average cost), and coverage limits. It stops short of describing error behavior, rate limits, or how many wallets are returned per call.

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 ranking definition and scope are front-loaded, and the pricing/payment mechanics follow in a logical order. It is a single dense paragraph with a couple of parenthetical asides that could be tightened, but essentially every clause conveys scope, cost, or invocation mechanics.

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?

For a paid, no-annotation, no-output-schema data tool, the description supplies what an agent needs: what is ranked, how it is computed, how fresh it is, what is excluded, what it costs, and how to pay. Response field detail is only sketched, but the absence of an output schema is offset by the mention of win/loss, open cost, and latest buys.

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 the single `payment` parameter is already documented, which sets a baseline of 3. The description adds real meaning beyond the schema by explaining the two-call handshake: the first call without `payment` returns terms, and the second with a signed payload completes the purchase in-call.

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 precise verb-and-resource statement: wallets ranked by REALISED profit over the last 24h, closed trades only, average cost, with win/loss, open cost and latest buys. That scope is specific enough to separate it from a raw trade stream, though it never names a sibling such as arc_whale_feed or arc_wallet_value, so the agent must infer the distinction.

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 documents the x402 purchase flow in detail (call once without `payment` for terms, sign with your own wallet, call again with `payment`), which is genuinely actionable invocation guidance. However, there is no explicit when-to-use versus alternatives guidance, and the stated exclusions (launch insiders, bot-like wallets, USDC-paired pools only) are data-scope limits rather than tool-selection advice.

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