token_safety

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

With no annotations, the description fully discloses behavioral traits: it is read-only ('no wallet, key, or signature needed'), mentions latency ('a cold simulation can take a few seconds'), and discloses cost ('Paid per call in USDC on Base via x402'). It also describes the output structure (JSON with grade, risk_score, is_honeypot, tradeable, flags). This goes beyond basic and covers operational concerns an agent must know before invoking.

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?

The description is well-structured and front-loaded with the purpose. It covers purpose, methodology, usage trigger, output format, and operational notes in a compact manner. While it is somewhat long, each sentence provides necessary information. It could be slightly tightened by removing redundant phrases like 'the token you are about to buy' which is already in the schema, but overall it is appropriate.

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 tool with this complexity (simulation, multiple analyses, output schema absent), the description is quite complete. It describes what it does, what it returns, and how it behaves operationally. It does not explicitly contrast with siblings, but the purpose clarity already achieves that. The only minor gap is not mentioning that it only supports the two chains in the schema, but that is in the schema. Overall, an agent has enough to decide when and how to call it.

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%, so both parameters are well-documented in the input schema. The description does not add extra semantic detail beyond what the schema provides (e.g., it does not elaborate on address format or chain selection). Since the schema already carries the full meaning, a score of 3 (baseline) is appropriate; the description adds no additional value for parameters.

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?

The description opens with a specific, actionable purpose: 'Decide whether an ERC-20 token is safe to trade before committing funds.' It names the resource (ERC-20 token) and the exact decision (safe to trade). It also differentiates from siblings by listing its comprehensive methodology (live simulation, contract analysis, GoPlus/honeypot cross-check) which clearly sets it apart from narrower tools like honeypot_check and contract_risk.

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?

Explicitly states when to use: 'Use it when an agent is about to swap into, approve, or accept a token it has not vetted.' This is clear and actionable. It does not explicitly mention alternatives or when not to use, but the context is sufficient because the tool is the comprehensive safety check, and siblings are more specific. A minor omission is not explicitly saying 'for a full safety verdict, use this, not the narrower checks'.

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