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

With no annotations present, the description carries the full burden and does so: $0.01 USDC per call via x402, written every 30 s, refused with 503 if data is older than 180 s, 404 for unscanned mints, nothing charged on failure, derived fields only and no reproduction of the source cards, and an explicit research-not-advice disclaimer. This is a richer operational profile than most annotation sets provide.

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?

Purpose is front-loaded in the first clause, and the trailing sentences each carry operatively useful facts (payment model, 48 h window, 30 s/180 s freshness rules, fee-on-failure, disclaimer). It is dense rather than padded, though the phrasing is compressed enough that a reader must work to unpack where behavior ends and disclaimers begin.

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?

An output schema exists, so return values need no prose. Combined with the coverage window, freshness SLAs, payment terms, error semantics, and scope caveats, an agent has everything needed to decide whether to call this tool and to interpret failures correctly.

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% for the single `mint` parameter, so the schema already documents type and intent. The description adds only the informal restatement that the token can be a Solana mint or a Robinhood Chain token, matching rather than extending the schema. Baseline 3 applies when the schema does the heavy lifting.

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 a specific verb (grade A-F) and resource (Solana or Robinhood Chain token) and enumerates the exact inputs that drive the grade: holders, top-10 share, largest holder, snipers, bundles, dev holding, fresh wallets, curve progress. It is clearly a distinct artifact-analysis tool, but it never names a sibling, leaving ambiguity against sol_token_verdict, rh_token_verdict, and rh_token_rugcheck.

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?

Gives concrete inclusion criteria (tokens the desk scanned in the last 48 h), explicit failure behavior for out-of-scope calls (404, not charged) and for stale data (503, not charged), plus cost. There are no exclusions or alternatives named, so an agent still has to infer whether a verdict tool would be better for the same mint.

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