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

No annotations are provided, so the description carries the full burden. It discloses the checks performed and a cost of $0.01 USDC, but does not explain whether payment is required or optional (given the default null), how errors are handled, or any side effects. The cost disclosure is helpful but incomplete.

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 description is a single, focused sentence that front-loads the core purpose and lists key details (chains, checks, cost). It is efficient with no fluff, though it could have used a second sentence to clarify payment semantics.

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?

An output schema exists, so return values are covered. However, the description does not explain the payment parameter, lacks explicit usage guidance, and does not mention any prerequisites or limitations. For a tool with three parameters and zero schema coverage, more context is needed for an agent to call it correctly.

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 0%, so the description must compensate. It lists allowed chains, giving some meaning to the chain parameter, but it does not explain the address parameter (though obvious) or the payment parameter. The cost mention hints at payment but does not clarify whether it is mandatory or optional. This is insufficient for a tool with three parameters.

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 clearly states the tool performs an on-chain contract check, enumerates the supported EVM chains, and lists specific checks (ownership renounced, LP burn share, ERC-20 metadata, red flags). This is specific and distinguishes it from generic token tools.

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 implies the tool is for contract checks but does not explicitly state when to use it versus alternatives like precheck or token_risk. No exclusions or alternative conditions are provided, leaving the agent to infer usage.

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