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

Goes well beyond the readOnly/openWorld annotations: discloses the quota (3 free calls/day shared across tools), the paid path ($0.01 USDC via x402 or card credits) and exactly where payment goes (params._meta["x402/payment"]), plus the data provenance (GoPlus + DexScreener) and the 'every flag names its source field' guarantee. These are precisely the operational facts an agent needs before calling.

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?

Dense and largely front-loaded, with the usage clause at the back working as a clear call to action. The pricing/quota sentence leads the description, which is defensible for a paid tool but delays the actual purpose statement slightly, making the opening feel like a billing notice rather than a tool summary.

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?

The tool has an output schema, yet the description still previews the return shape (per-token risk level/score/flags/liquidity/price plus per-risk-level counts and averages). Combined with cost, payment mechanics, data sources, and chain scope, nothing material is missing for a low-complexity, two-parameter 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?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: 'addresses' are token contract addresses (not the wallet itself), comma-separated, max 20, ERC-20 only, and the chain is constrained to Base or Ethereum. The max-20 constraint and token-vs-wallet disambiguation are the kind of clarifications that prevent misuse.

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?

States a specific verb and resource ('Token portfolio risk scan'), the scale limit (up to 20 ERC-20 tokens in one call), and the exact per-token payload (risk level, score, flags, liquidity, price). An agent can immediately tell this is the bulk risk-ranking tool rather than a single-token lookup.

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?

Provides an explicit 'When to use' clause: risk-rank up to 20 holdings of a wallet in one call. However, it never names the obvious alternatives (token_risk, token_score, rug_check, token_compare), so the agent must infer that those are the single-token or comparison variants from their names alone.

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