Base Token Verdict ($0.02)

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

Annotations only say readOnly/openWorld/non-idempotent; the description adds substantial context beyond that — the $0.02 USDC x402 charge, the X402_PRIVATE_KEY requirement for automatic payment, and the fact that 4xx/5xx failures are not billed. These are exactly the operational facts an agent needs before calling a paid endpoint. It stops short of saying whether results are cached or how long a simulation takes, so it is strong but not exhaustive.

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?

Three compact sentences with zero filler, and the behavioral constraints (pricing, billing on failure, informational-only) are clearly separated at the end. The only weakness is ordering: the price is front-loaded ahead of the purpose, so an agent skimming the first clause learns the cost before learning what the tool does.

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?

No output schema exists, so the description has to convey the return value — 'A-F safety verdict' plus the enumerated checks gets close, making the shape of the report predictable. Given the tool performs paid on-chain simulation, a bit more about latency or result structure would round it out, but nothing essential for correct invocation is missing.

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?

With a single parameter and 100% schema description coverage (the schema already documents 'Base ERC-20 token contract address' plus a regex pattern), the description cannot add much and doesn't — 'Base ERC-20' repeats the schema wording. Baseline 3 applies when the schema already carries the parameter semantics.

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 deliverable ('A-F safety verdict for a Base ERC-20') and then enumerates the exact checks performed: metadata/supply, ownership, proxy upgradeability, DEX liquidity vs WETH/USDC, honeypot simulation with taxes, holder concentration. This is unambiguous and cannot be confused with any sibling such as pre_trade_check or insider_buys, which have entirely different verbs and resources.

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 the domain of applicability clear (a Base ERC-20 contract address, read from Base mainnet) but never states when to reach for this instead of a related sibling like pre_trade_check, nor does it set exclusions (e.g. non-Base chains, non-ERC-20 assets). Usage is implied by the input and the safety framing rather than stated.

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