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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so safety is covered; the description's 'Reads only' is confirmatory rather than additive. What it does add is the scope of the underlying lookup — it is a free, external, on-chain report enumerating authority, tax/hook, and liquidity dimensions, which tells the agent this is a network-dependent analysis rather than a local read. No caveats about unknown/unindexed tokens or latency are given, so it is not a 5.

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 sentences, front-loaded with the deliverable and its contents, then the parameter rule, then the trigger condition, closing with a one-word safety note. Every clause carries information an agent needs; nothing is 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?

There is no output schema, so the description must carry the return-shape burden, and it does so by listing the report sections and noting a verdict with a score. With only 2 parameters and full schema coverage that is sufficient to call the tool. It does not cover failure or degraded modes (unindexed token, unsupported chain value), which keeps it from a 5.

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 the baseline is 3, and the description clears that bar by tying parameter choice to chain: 'On Solana pass the mint address; on an EVM chain pass the token contract address.' That formats the address input by chain in a way the schema only states in compressed form. Minor mismatch: the schema enum offers only 'solana' and 'robinhood' while the prose says 'an EVM chain', so the EVM/label mapping is slightly looser than the enum.

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 ('Run the free risk report on a token') and then enumerates exactly what the report covers: mint/freeze authority, transfer taxes and hooks, permanent delegates, liquidity, holder concentration, and a scored verdict. That enumeration is what separates it from narrow siblings like check_token_tax, check_frozen_tokens, and check_token_delegates, which each cover only one of those dimensions.

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 names the triggering user intent: 'Use it when a user asks whether a token is safe, a rug, or a honeypot.' That is a clear when-to-use signal. It stops short of the top score because it never names an alternative or an exclusion (e.g., when the narrow sibling checks are preferable), leaving the agent to infer the routing itself.

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