chainpeek: token safety check for an ERC-20 on Base or Ethereum: honeypot, tax and contract risk in one verdict

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

Far exceeds the annotations (readOnly/idempotent/openWorld): it discloses the mechanism (simulated buy and sell-back measuring honeypot, buy/sell/transfer tax, pool, revert reason; contract flags for upgrade, mint, blacklist, fee setters, pause, verification), the heuristic-vs-audit caveat, error semantics (422 non-contract, 5xx failing RPC and not charged), latency, price, free tier, and an untrusted-data warning.

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 use case and alternatives, and nearly every sentence carries operational value (errors, pricing, latency, safety caveat). However it is a single dense paragraph with several crammed clauses, so it is not maximally scannable.

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?

For a 2-param read-only tool with an output schema, the description covers everything an agent needs: when to call it, what the verdict contains, its heuristic limits, failure modes, cost, rate limits, and a prompt-injection caution. Nothing material 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?

Schema description coverage is 100% and the two parameters (chain enum, address pattern) are fully self-documented, so baseline 3 applies. The description restates the Base/Ethereum scope and ERC-20 address notion but adds no format or syntax detail beyond 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?

States a specific verb+resource+scope: deciding whether an ERC-20 token on Base or Ethereum is safe to buy or interact with. It explicitly differentiates from sibling tools by name (token_verdict for a written summary/share card, check_solana_token_safety for Solana), so an agent can route without opening schemas.

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?

Gives an explicit when-to-use trigger ('when an agent must decide whether an ERC-20 token ... is safe to buy or interact with') and names concrete alternatives with the condition that selects them. The distinction from token_verdict and the Solana tool is unambiguous.

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