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 payment model (0.020 USDC per call over x402, payable on Base or Solana), the supported chains, and the honest disclosure that a list of what was *not* checked is returned. It stops short of describing failure behavior (what happens to an unpaid or unsupported-chain call) or latency, so a top score is not warranted.

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 the value proposition, then signals, then fingerprint, then chains, then price — a sensible ordering with no filler sentences. The first sentence is long and comma-heavy, but every clause carries distinct information.

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, and the description compensates well by enumerating the returned contents (grade, plain-language summary, per-signal evidence, unchecked list, fingerprint). Completeness is only dented by the dangling 'since' instruction, since an agent following it would find no such parameter to populate.

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 description supplies the missing meaning for 'chain' by listing the four supported networks, which the schema only illustrates with a bare 'Example: base'. However, it instructs the agent to pass a fingerprint as 'since' — a parameter that does not exist in the input schema — creating a real mismatch, and it says nothing about the format of 'token' beyond the schema's example.

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 — a token risk verdict delivering an A-F grade plus the underlying signals — and scopes it to the decision it supports ('before you buy, hold or accept a token'). The enumerated signal list (mint, pause, blacklist, fee powers, proxy, liquidity, age, volume) makes the output distinguishable from the sibling evm_token_info metadata 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?

Explicitly frames the decision context where this is the right call, and explains the repeat-call pattern by instructing the agent to send back the fingerprint as 'since' to detect changes. It also constrains to four chains. It never names the sibling risk_portfolio or states when portfolio-level risk is preferable, so the alternative routing is left to inference.

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