security.token_risk

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it delivers: it names the data sources (GoPlus with Honeypot.is fallback), explains the dangerous null-field semantics ('Do NOT treat a null field as safe'), and states coverage limits. It also clearly documents the success and failure return shapes, which helps the agent reason about outcomes.

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: purpose first, then when to use it, then a critical caveat, then alternatives, then args and return format. Every sentence earns its place, including the data-source note and the LP lock/burn boundary, without padding.

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 two-parameter risk-checking tool with no output schema, the description is complete. It documents both parameters, the returned fields on success, the error shape on failure, important interpretation guidance, and the relevant sibling-tool alternatives. Nothing an agent needs to invoke and interpret this tool correctly 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 0%, so the description must explain both parameters itself. It does this well: chain_id is defined as an EVM chain id with a concrete Base example, and contract_address is specified as a 0x token contract address. This fully compensates for the missing schema descriptions.

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 verb and resource ('Check a token contract for honeypot/scam risk before buying') and enumerates the concrete signals it returns, such as is_honeypot, buy/sell tax, risk_level, and holder count. It also differentiates itself from nearby sibling tools by explicitly stating what it does not cover and naming alternatives.

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?

Usage is explicitly contextualized: 'Use this right before entering a position on an unfamiliar or newly-listed token.' It also gives a clear exclusion boundary ('does not cover LP lock/burn status') and routes the agent to get_contract_health_audit or get_token_diagnostic as alternatives, which is exactly the kind of when-and-when-not guidance an agent needs.

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