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

Goes well beyond the readOnly/idempotent/non-destructive annotations: discloses the $0.009 USDC x402 price, that unpaid HTTP calls return 402 even for invalid queries, that signed calls with bad arguments are rejected pre-settlement and not charged, that billing only occurs on non-error results, and that responses may carry cached/stale/cacheAgeMs with the meaning of stale=true. It also flags the null-return condition for copyTradeScore (no close lasting at least 3 seconds) and the score's methodology (3s delay, 3.6% round trip, shrinkage, bot/insider penalties).

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 purpose and alternatives, then payment mechanics, then response-state semantics — a sensible ordering. It is dense and mostly earns its sentences, but a few lines duplicate structured data (the txLimit range/default) and the HTTP endpoint pricing note is marginal for a tool-calling agent.

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?

There is no output schema, so the description must carry return-value semantics — and it does, covering holdings, PnL windows, win rate, labels, copyTradeScore/Grade composition, and cached/stale/cacheAgeMs. Combined with the billing model and failure modes, an agent has everything needed to invoke and interpret results 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?

Schema description coverage is 100%, so both parameters are already documented. The description's 'txLimit is an integer from 5 to 25 and defaults to 20' merely repeats the schema and adds no syntax or behavioral nuance; the address parameter is not discussed at all. Baseline 3 applies when the schema carries the parameter burden.

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 opening sentence states a specific verb-and-resource combination ('priced holdings and windowed PnL'), scopes it to one Solana wallet, and enumerates the concrete outputs (USD valuation, realized/unrealized PnL, win rate, evidence-backed labels). It is immediately distinguishable from wallet_preview and wallet_quick, which are named as narrower alternatives.

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?

Explicit routing guidance: 'Call free wallet_preview first if you only need SOL balance and last-active time, or wallet_quick for a cheaper copy-trade screen.' Both alternatives and the exact condition selecting each are named, so an agent can choose without opening sibling schemas.

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