token_report

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

No annotations provided, so description carries full burden. It discloses the composite nature, the verdict format, the paid service requirement (USDC on Base with funded wallet), and the 402 error for unpaid calls.

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?

Description is detailed but front-loaded with the core purpose. Some redundancy (e.g., repeating 'PAID x402 service'), but overall efficient for the tool's complexity.

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?

Given no output schema and tool complexity, the description adequately covers return values (verdict, reasons, underlying reports) and operational context (payment, chain support). Complete for an agent to understand and invoke 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 baseline is 3. Description adds that 'token' is an ERC-20 address on Base and 'chain' defaults to 'base', but these are already in the schema descriptions. No additional semantic enrichment beyond 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?

The description clearly states the tool's purpose: a composite that runs token-safety checks, liquidity removal, and whale activity on a Base ERC-20, returning a single verdict. It distinguishes from sibling tools (token_safety, liquidity_pulls, whale_swaps) by being a one-call alternative.

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 says 'one call instead of five' and 'cheaper than buying... separately', indicating when to use this composite over individual tools. Also notes unpaid requests return 402, implying payment is required.

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