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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, and the description adds material context beyond them: static-analysis (not simulation) semantics, the scope of the selector scan (145 signatures), the 0-100 risk score output, the $0.01 USDC per-successful-call pricing model via x402 on Solana, and a same-tool HTTPS fallback. That is exactly the kind of cost/auth/limitation context annotations cannot carry.

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-loads purpose and capabilities, then closes with the two most decision-relevant facts (pricing and static-analysis caveat). The first sentence is a very long clause chain, but nearly every clause carries distinct information an agent needs; there is little pure filler.

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 does the work of enumerating return fields (metadata, proxy detection, standards, selector-derived capabilities, risk score), and it discloses cost and transport. Remaining gaps are error behavior and rate limits, which are minor for a read-only, idempotent lookup.

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 description coverage is 0% with two parameters, so the description must compensate. It effectively enumerates the accepted `chain` values (Ethereum, Base, Arbitrum, OP Mainnet, Polygon, BNB Chain), but says nothing about the `address` format, required casing/checksum, or whether non-contract addresses error — leaving the required parameter undocumented in both schema and description.

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 (introspection of an EVM contract) and enumerates exactly what is returned: bytecode size/hash, proxy patterns, ERC standards, token metadata, owner()/paused(), selector scan, and risk score. It also names the chains covered, so an agent can distinguish it from sibling read tools like evm_read or evm_selector_decode without opening any schema.

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?

Includes an explicit exclusion — "Static analysis only — not a honeypot simulation" — plus a read-only statement and an alternate HTTPS endpoint, giving clear context for when this tool fits. It does not name sibling alternatives (e.g. wallet_risk_basic for wallet-level risk or evm_selector_decode for a bare selector lookup), so routing between similar tools is still partly inferred.

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