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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety semantics are covered; the description still adds real value with 'no key, no payment' cost/auth context and 'pinned to a block' reproducibility. It says nothing about failure modes, latency, or what happens for the 'undeployed' address case beyond listing that verdict as an outcome.

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?

Front-loaded with the action and workflow timing, followed by a compact list of outputs and the cost note — no filler sentences. It is a single dense sentence that runs long, but every clause carries information an agent would otherwise have to query.

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?

With no output schema, the description takes on the job of describing returns and does so thoroughly (verdict categories, 0-100 risk score, proxy/implementation, controller kind, capability flags). Cost and authentication are also covered; the remaining gap is error/edge behavior for malformed or unsupported inputs.

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% with patterns, defaults and an enum already documented, so the baseline is 3. 'Pinned to a block' reinforces the block parameter's purpose but adds no format or behavioral detail, and the chain enum (ethereum/base) is left entirely to the schema.

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 a specific verb+resource formulation ('pre-execution safety check of a contract') and enumerates the verdict taxonomy and risk score the caller receives, so the agent knows exactly what it is asking for. It does not explicitly name a sibling tool or contrast itself with the scan_* tools, which keeps it below a 5.

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?

'before an agent interacts with it' pins the tool to a clear moment in the agent workflow, and 'One-call' signals it consolidates checks that might otherwise take several scans. There is no when-not guidance and no named alternative for deeper investigation, so the routing burden is only partly lifted.

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