token_ai_verdict

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

No annotations are provided, so the description carries the full disclosure burden and does fairly well: it names the exact output contents (grade A–F, SAFE–DANGER label, 0–100 score, honeypot sell simulation, buy/sell tax, mint/freeze/owner powers, liquidity, verdict card), states the data provenance constraint ('written strictly from the check data: no invented numbers, no price predictions'), and flags 'Not financial advice', cost and latency. Still missing: how the USDC payment is authorized/charged, and whether the call is a pure read with any rate limits.

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?

It is a single run-on paragraph packed with nested parenthetical enumerations, and its opening clause restates the title ('AI token verdict built on real on-chain checks'). The core intent is front-loaded, but the dense listing of output fields and the absence of any structural breaks make it harder to scan than it needs to be.

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?

There is no output schema, and the description compensates well by enumerating what comes back and constraining the AI text's provenance. Cost and latency are disclosed. The main gap is the schema's `required: []` versus the description's implication that a token target must be supplied, leaving the agent unsure whether the call can succeed without one.

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 50%: `token` already documents that it accepts a 0x contract address or Solana mint, and `chain` carries an enum with a default. The description largely repeats the enum values (Base, Ethereum, BSC, Arbitrum, Polygon, Avalanche, Optimism, Solana) without adding format, default, or validation semantics, so it neither compensates for the undocumented `chain` parameter nor exceeds 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 concrete verb and resource: send a token contract address or Solana mint, receive a full token verdict plus an AI-written trader take. It implicitly differentiates from the sibling token_verdict by describing this as 'everything from token-verdict ... plus an AI-written take', but it never names token_verdict (or token_precheck/token_security) as an explicit alternative, so sibling routing is left to inference.

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 implied — supply a contract address or mint and get a verdict — and the cost ($0.015 USDC) and p99 latency (15000ms) give useful call-time context. However there is no explicit when-to-use/when-not guidance, no statement of prerequisites or payment setup, and no direct comparison to the many sibling token tools (token_verdict, token_security, token_simulate), so the agent must guess when this is preferable.

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