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

With no annotations, the description carries the full burden and does so well: it discloses rate limits (3 calls/hour/IP, shared with the website), the paid escalation path ($0.030/call over x402 at /v1/safety), the scope boundary ('our own recording'), and a behavioral constraint ('facts and flags only, never advice'). It does not mention latency or failure behavior for invalid mints, but the operational context is unusually rich.

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?

Front-loaded with the core question, then the evidence categories, then the emitted flags, then operational constraints. Each clause carries information, though the flag enumeration and the pricing/endpoint clause make it denser than a two-sentence ideal.

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 or annotations, the description compensates by enumerating the exact flags returned and stating the facts-only stance, which is enough for an agent to interpret results. Missing only edge-case behavior (invalid/non-existent mint) and the response container format, which are minor for a single-parameter read tool.

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?

There is a single parameter (mint) with 100% schema description coverage ('Solana token mint address'), so the schema already carries the semantics. The description adds no format, validation, or derivation detail beyond what the schema states, making the baseline 3 appropriate.

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 opens with a specific question form that names the exact resource (a Solana token mint) and enumerates the four check categories it covers: mint/freeze authority, holder concentration, Token-2022 transfer risks, and deployer launch record. It also lists the concrete output flags, so an agent can tell precisely what this tool returns and how it differs from siblings like deployer, launch, or pool.

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?

Usage context is implied rather than stated: an agent can infer this is the pre-trade safety gate, and the pricing clause hints at call budgeting. However, it never says when to choose this over the overlapping siblings (deployer, launch, known), nor when it is unnecessary. No explicit when-not guidance or alternative routing.

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