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 fully discloses that the tool is 'Read-only; never signs or sends,' costs '$0.02 per call,' requires no account/API key, and typically returns in 'under 2s.' It also explains the output (0–100 risk score with reasons) and the specific risk factors it evaluates, giving substantial behavioral 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?

The description is dense but each sentence provides valuable information: purpose, output details, use case, cost, speed, safety, and parameter format. It is front-loaded with the core verdict. The main inefficiency is that the parameter description is appended as a trailing line, but it remains compact and free of filler.

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?

For a one-parameter tool with no annotations and no output schema, the description is impressively complete: it covers purpose, input, output nature, use case, cost, safety, and performance. The only gap is that it doesn't define the risk score thresholds (e.g., what score constitutes 'go' vs 'no-go') or the exact return structure, but this is not critical given the tool's simplicity.

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?

The input schema only defines 'mint' as a required string with no description, so schema coverage is 0%. The description compensates by explicitly explaining the parameter: 'mint: SPL token mint address' and providing a concrete example address. This fully clarifies what value the agent needs to supply.

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 the tool's function: 'Go/no-go risk verdict on a Solana SPL token before you buy it,' specifying the verb (verdict/returns a risk score), the resource (SPL token), and the context (pre-purchase). It also differentiates from siblings by explicitly focusing on risk screening rather than transactions or wallet inspection.

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 provides explicit when-to-use guidance: 'Use when you are about to buy, swap, or approve an unfamiliar mint.' It also explains the value proposition ('Replaces 4+ RPC round-trips plus a quote sweep'). However, it does not explicitly contrast with sibling tools (e.g., 'instead of inspect_wallet'), making the differentiation mostly implicit.

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