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

Goes well beyond the read-only/open-world annotations: it discloses the payment model ($0.004 USDC via x402, accepted chains), that x402-capable MCP clients pay automatically, the 10-minute result cache, the basis of the verdict (on-chain contract code, pools, real buy/sell simulation), and a free sample invocation. Payment/auth requirements and caching are exactly the kind of context annotations cannot express.

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 core capability, then output shape, caching, parameters, pricing and a sample — every block carries usable information. It runs long as a single paragraph and includes mild marketing framing ('cheaper per token than any single-token verdict'), but nothing is truly wasted.

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 fully specifies the return contract (decision, grade A–F, score, honeypot flag, main reason). Combined with chain coverage, batch limit, caching and payment mechanics, an agent has everything needed to invoke this paid multi-chain tool 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%, so the baseline is 3, but the description adds value on top: it explicitly names the three accepted parameter spellings (token, tokenAddress, tokens), confirms the 5-address batch cap and the supported chain list, and supplies a concrete example input that disambiguates the anyOf/alias structure.

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 and resource: a honeypot/rug pre-trade check that returns one of ALLOW/CAUTION/BLOCK with grade, score, flag and reason. An agent immediately knows the output shape and the multi-chain, batch nature. It hints at differentiation from single-token verdict siblings ('cheaper per token than any single-token verdict') but never names token_verdict, token_security or token_simulate, so sibling routing stays partly inferential.

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?

Clearly frames the use case: 'before a trade, built for trading bots that check every token in a loop', with batch limits (up to 5) and caching making the loop scenario concrete. It implies the alternative is single-token verdict tools but does not explicitly say when to choose this over token_verdict/token_security, and gives no exclusions.

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