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

Annotations (readOnly, idempotent, openWorld) cover the safety profile, and the description adds what annotations cannot: the $0.01 paid cost, the 402 challenge on non-payment, the automatic payment via the npm package, and the exact returns. The 'a call that fails after payment settles nothing' (in the payment param schema) and 'returns verdict with exact risks' complement the no-mutation hints. No contradiction with annotations.

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 most critical gate ('PAID ($0.01 USDC via x402)') before the purpose, which is the right priority for a paid tool. The feature list is dense but each item is information-bearing, and the payment-flow sentence earns its place. Slightly verb-heavy near the end ('Not financial advice'), but every sentence contributes signal.

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?

Complete for a complex, paid, two-step tool. Output schema covers return values, schema covers all params at 100%, and the description covers cost, payment flow, verdict format, and auto-pay. The riskiest part — the 402→payment handshake — is fully described in both description and schema, so an agent has everything needed to call this 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 100%, and the schema already documents all three params thoroughly — the payment param in particular is extensively described (EIP-3009 payload, howToPay payloadTemplate, PAYMENT-SIGNATURE header). The description adds little param-specific meaning beyond what the schema provides, which matches the baseline-3 expectation 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?

Clear verb+resource: 'On-chain safety verdict for any EVM token' with specific deliverables (verdict safe|caution|danger). The feature list (honeypot, taxes, owner privileges, LP lock, liquidity) crisply distinguishes it from siblings like token_metadata and token_price, and the 'BEFORE you trade it' framing sets the exact scope. The verdict output is a distinct deliverable that differentiates it from token_report.

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?

Strong context: 'BEFORE you trade it' tells the agent when this is the right tool, and the cost is front-gated. The payment guidance is explicit about the two-step 402-then-payment flow. However, it never names sibling alternatives (token_report, token_metadata) or states a when-not condition, so some routing is left to the agent rather than being explicit.

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