token_verdict

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

No annotations are provided, so the description carries the full burden, and it delivers unusually rich context: the numeric cost ($0.009 USDC per call), p99 latency (8000ms), the underlying check battery (honeypot sell simulation, taxes, mint/freeze/owner powers, liquidity, age), and the grading rule that young/illiquid tokens cap at C. It stops short of stating auth/payment mechanics or failure behavior, so not quite a 5.

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 output (grade, label, score, reason) is front-loaded immediately after the tool name, which is good structure. The single long paragraph is dense and slightly run-on but nearly every clause carries operational information; little 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?

With no output schema, the description must describe returns, and it does: grade, label, 0-100 score, one-line reason, key facts, share_text and share_url. It also covers supported chains, cost and latency. Only payment/auth mechanics and error cases are left implicit, keeping it just under fully complete.

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?

With 67% schema coverage the description still adds meaning: it notes tokenAddress is an accepted alias, that chain defaults to base, that Solana is auto-detected and which chains are supported. This complements the schema's enum rather than repeating it. It doesn't explain the accepted address format beyond the schema, hence not a 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 and resource: it produces an 'instant buy-or-avoid verdict' i.e. a grade A-F with label, score and reason for a token. The scope (buy/avoid decision) is unambiguous. However it never distinguishes itself from close siblings like token_security, token_precheck or token_ai_verdict, so an agent can't tell which token-grading tool to pick from the description alone.

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 framing 'instant buy-or-avoid verdict' implies the use case (quick go/no-go on a token), which is clearer than average. But there are no explicit when-to-use rules, no prerequisites, and no mention of the competing token-analysis siblings, so routing decisions are left to inference.

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