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

Beyond the annotations (readOnly/idempotent/non-destructive), it discloses traits the agent could not otherwise know: an empty call returns a case index, unauthenticated or trial keys get a truncated preview (summary, detectors, hash, first transactions), and the output is scoped to on-chain facts with no intent or identity claims. The determinism implied by a SHA-256 integrity hash is also useful behavioural context.

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 front-loaded with the resource and packs only high-value content, but the opening is a long semicolon-separated run-on that is closer to a feature dump than a structured list. Slightly reformatting the output inventory would improve scanability without losing content.

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 full burden of describing the return payload, and it does so completely: detector confidence plus false-positive notes, Solscan-linked signatures, timeline, P&L, and funding graph. Access-tier behaviour and the empty-argument case are also covered, leaving nothing an agent needs before calling it.

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 the baseline is 3, but the description adds real meaning: it maps the three lookup modes to case types (token, creator group, caller) and tells the agent that omitting all of them yields an index rather than an error. That last point is not derivable from the schema's optional parameters.

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 states a specific resource — an evidence pack for a flagged pump.fun token, creator wallet group or caller — and enumerates exactly what it contains (detectors, tx evidence, timeline, P&L, funding graph, integrity hash). That content profile makes it unmistakable against siblings like token_manipulation_score, kol_scorecard or trace_wallet, which return scores or traces rather than a packaged case file.

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?

It gives concrete lookup guidance — case id prefixes TK-/CL-/KOL-, mint, or wallet — plus the useful edge case that no argument returns an index of cases, and it explains trial vs paid key behaviour. What is missing is any explicit routing statement against the sibling tools (e.g. when to open a case file instead of calling token_manipulation_score first).

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