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. It openly states that missing data is reported as 'unknown' rather than a pass, and that each verdict is filed as a claim and scored publicly after 7 days – important transparency about how results are generated and validated. It does not mention the two-step payment flow (covered in the schema) or any side effects, but it does meaningfully disclose the tool's honesty policy.

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 dense but every sentence earns its place: it states the output scale, the criteria, the unknown-handling policy, and the calibration mechanism. It is front-loaded with the core purpose and then adds specifics without any fluff. The structure is logical and easy to parse.

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 the tool's complexity (multiple risk factors, no output schema), the description provides substantial context: it enumerates the criteria, the verdict levels, and the transparency policy. It does not describe the exact output structure (e.g., fields in the verdict), but it says 'with every finding behind it', implying detailed output. The payment flow is in the schema, so not repeating it is acceptable. The only gap is handling of invalid or nonexistent tokens, but overall it is complete enough for an agent to understand what it will receive.

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% – every parameter (chain, token, payment) is already documented with type and format. The description adds no new semantic detail about parameters beyond reinforcing that the token is on Solana or Base. Since the schema carries the full parameter explanation, the description's contribution is minimal, keeping this at the baseline for high schema coverage.

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 a specific verb and resource: 'get a risk verdict for one memecoin'. It enumerates the specific risk factors considered (liquidity, mint authority, honeypot, sell tax, lock, concentration) and the output scale (LOW to CRITICAL). It is unambiguously distinct from sibling tools like get_new_memecoins (discovery) or get_market_overview (broad market).

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 description makes it obvious when to use this tool: when an agent needs a risk assessment for a specific token on Solana or Base. It does not explicitly name alternatives or state when not to use it, but the specificity ('for one token') and the listed criteria clearly imply its scope. No misleading or exclusionary information is present.

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