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

Despite readOnlyHint/openWorldHint/destructiveHint already declaring a safe read operation, the description adds substantial behavioral detail: FIFO-matched PnL, routed-hop exclusion, dual open-bag valuation, withholding conditions for the reconciliation price, roster membership behavior, and the $0.03 cost. This goes well beyond what annotations provide and discloses important edge cases.

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 description is information-dense but packaged as a long, run-on sentence that is harder to parse. The cost is mentioned multiple times ('Costs $0.03', 'still one $0.03 call', 'paid $0.03 — see instructions'), which is redundant and not concise despite the overall richness.

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?

With no output schema, the description carries the full burden of explaining what the caller gets: the PnL metric, win rate, hold style, open-bag markings, leaderboard comparison, reconciliation price, and the found:false case. It also covers the cost, the chain, and the roster constraint, making it complete for a complex paid read tool.

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?

The schema already describes the single address parameter at 100% coverage. The description adds meaningful domain semantics by explaining that the address must be in the tracked 100-wallet roster and that an outside address still returns found:false, informing the agent about valid inputs and the fallback response.

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 clearly identifies the resource (a Robinhood Chain wallet trading receipt) and the specific content (realized PnL, win rate, hold style, open bags, leaderboard comparison). It also distinguishes this from the sibling Solana receipt tool by naming the chain and the tracked roster, so an agent can tell them apart without opening schemas.

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?

The description makes clear this is for Robinhood Chain wallets and that only a tracked roster of 100 wallets is supported, with an outside address returning found:false. It does not explicitly name the alternative Solana receipt tool, but the context strongly implies the chain-specific usage and the roster limitation serves as practical usage guidance.

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