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

Annotations only declare a read-only, open-world, non-destructive profile, but the description adds substantial non-obvious behavior: a $0.015 USDC per-call fee paid in-band via x402, accepted payment chains, and the constraint that the AI text is written strictly from check data with no invented numbers or price predictions, plus a not-financial-advice disclaimer. This is exactly the kind of context the annotations cannot convey.

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?

Purpose is front-loaded in the opening clause, and the long parenthetical enumerating verdict contents is justified because there is no output schema. It is dense and slightly over-packed (pricing, sample, disclaimer, AI sourcing all in one block), but every sentence earns its place.

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 carries the full return-value burden and does so thoroughly: grade, SAFE/DANGER label, 0-100 score, honeypot simulation, taxes, mint/freeze/owner powers, liquidity, verdict card, plus the AI headline and sentences. Nothing an agent needs to invoke or interpret it is missing.

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?

At 50% schema coverage, the description must carry weight and does: it enumerates the chains matching the chain enum and explains the token parameter accepts a 0x address or Solana mint, matching the schema alias note. A concrete example input reinforces the format. It adds meaning beyond the raw enum, though it does not document the default.

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?

Specific verb+resource: an AI-augmented token verdict on-chain check. It explicitly distinguishes itself from sibling token_verdict by stating it delivers 'everything from token-verdict' plus an AI-written take, so an agent can tell exactly where it sits in the family without opening a 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?

Clear context: send a token contract address or Solana mint, and the supported chains are enumerated. It even supplies a concrete free-sample call. It stops short of an explicit when-not rule (e.g. 'skip this if you only need the raw grade'), so it does not reach the 5 tier.

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