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

With no annotations at all, the description carries the full burden and does reasonably well: it discloses that sources are fail-soft and enumerated in the response, which warns the agent that results may be partial and which source failed. It does not cover latency, rate limits, or error behavior, but the fail-soft disclosure and source attribution are meaningful beyond-schema context.

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?

A single dense sentence with zero filler; the core purpose is front-loaded and the sources/chain defaults follow logically. It is slightly run-on and could be split for scanability, but no clause is 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?

Absent an output schema, the description still conveys the return shape (risk flags, a four-grade risk_level, listed sources), which is what an agent needs to interpret results. It leaves the actual grade labels and the meaning of individual flags unspecified, a minor but real gap for a tool whose whole value is the verdict.

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 0% and the schema lists bare string types with no descriptions, so the description must compensate and largely does: chain defaults to base and accepts chainId 8453, 1, or 56, and address is constrained to one contract address. It stops short of format details (checksum/casing, whether 'base' is case-sensitive), which keeps it below 5.

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 (ERC-20 token safety check for one contract address) and enumerates exactly what is checked: honeypot/tax simulation, liquidity and pair age, plus on-chain reads distilled into risk flags and a four-grade risk_level. It is clearly distinct from siblings like wallet-lookup, dex-quote, or wallet-lookup-pro, which address different objects.

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?

The description scopes usage to a single contract address on Base, Ethereum, or BSC, which implicitly tells the agent when this tool applies. However, it never explicitly says when to prefer it over adjacent tools (e.g., wallet-lookup-pro for address reputation, dex-quote for pricing) and gives no exclusions or prerequisites.

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