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

With no annotations, the description carries the full burden, and it does disclose two non-obvious behavioral facts: the call costs $0.01 USDC via x402 on Base, and the return is a low/medium/high verdict with reasons. It does not cover failure modes (unverified/unrecognized token, unsupported contract) or whether results are cached, so it stops short of fully characterizing the interaction.

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?

A single dense sentence packed with the concrete checks, followed by the output shape and then the price. Everything is front-loaded with zero filler, and the pricing sentence is essential for a paid tool rather than padding.

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?

For a one-parameter read tool with no output schema, the description covers what is checked, what the verdict looks like, the chain, and the payment model, which is nearly everything needed to call it correctly. The missing piece is how it relates to tokenrisk_verdict and what happens on unsupported or unverified tokens.

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?

There is exactly one parameter and schema description coverage is 100% ('ERC-20 contract address on Base'), so the schema already does the work. The description only repeats the chain scoping and adds no format or validation detail beyond it, which is the baseline expectation.

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 gives a specific verb and resource ('Risk check of an ERC-20 token on Base') and then enumerates exactly what is inspected: proxy upgradeability, owner powers in bytecode, owner supply share, and Uniswap/Aerodrome liquidity. That is far more concrete than a generic 'check token' tool. The only gap is that it never distinguishes itself from the sibling tokenrisk_verdict, so an agent cannot tell the two apart from the text alone.

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 phrase 'before buying' implies a clear use context (pre-trade due diligence), which is useful but is the only usage signal. There are no exclusions, no prerequisites (e.g., token must be a verified contract), and no guidance on when to use tokenrisk_verdict instead, which is the obvious alternative.

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