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

Annotations already cover read-only, idempotent, non-destructive and open-world. The description adds genuinely new behavioral context: the tool is free, needs no key, serves only cached data from the last hour, and degrades to status=not_cached instead of erroring. That caching/failure behavior is exactly the kind of thing an agent cannot get from the annotations or schema.

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?

Two short sentences, well front-loaded: price tier first, then the payload, then the failure mode and auth note. No filler. Marginally terse on jargon ('shell check') but structurally tight.

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 carries the burden of explaining returns; it names the payload sections but not their structure or the possible verdict values, and 'shell check' and 'token facts' go undefined. Combined with its silence on sibling selection, it is adequate but leaves clear gaps for a tool whose output is the whole point.

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?

One required parameter with 100% schema description coverage ('Solana token mint address (base58)'), plus a base58 pattern constraint. The description adds nothing beyond the schema, so the baseline of 3 applies.

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 concretely what comes back for a Solana mint: verdict, token facts, shell check, holder summary, plus the not_cached fallback. That is a specific verb+resource with a clear scope. It does not name the sibling it differs from (check_solana_token_lite, analyze_solana_token), so an agent must infer the distinction from the word 'Free' and the one-hour cache rule.

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 'Free' label and the 'if it was scanned in the last hour' condition imply the intended use case and one exclusion (cache miss returns status=not_cached). But the description never says to use analyze_solana_token for a fresh/full scan or check_solana_token_lite for an intermediate tier, leaving the sibling choice to inference.

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