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

There are no annotations, so the description carries the burden, and it discloses several important facts: the result is deterministic, the call costs $0.01 via x402 (USDC), and it returns evidence (exact selector and byte offset) rather than a verdict. It does not explicitly state that the call is read-only or whether payment is required before the result is returned, so it falls slightly short of complete behavioral disclosure.

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?

The trigger condition comes first, followed by detection scope, return semantics, determinism, and cost, in that order. All five sentences add information, and none is redundant.

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?

Since there is no output schema, the description correctly explains what the result contains (evidence selectors plus offsets, and ownership-renounced status) and covers chains and pricing. It does not describe the response envelope or structure (for example, a per-check boolean versus a list), but for a two-parameter read tool this is nearly complete.

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 input schema already documents both parameters at 100% coverage, including the chain list. The description merely restates the supported chains in prose, and it adds no syntax, formatting, or defaulting rules beyond what the schema provides. A score of 3 is the correct baseline when the schema does the heavy lifting.

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 uses the specific verb-resource pair 'pre-trade risk check on a token' and states that it analyzes deployed bytecode and live state across five named chains. It lists exactly which powers are detected (mint, pause, blacklist, upgradeable proxy, mutable buy/sell tax) and whether ownership is renounced, so an agent can clearly tell it apart from evm_token_info (metadata), evm_balance, or crypto_sanctions.

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?

'Use when an agent must decide whether to touch a token at all' gives an explicit trigger condition, and the cost line ('$0.01 per call') helps an agent weigh whether it is worth calling. However, it does not name alternatives (such as evm_token_info or crypto_sanctions) or state any case in which the agent should not use it.

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