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

With no annotations, the description carries the behavioral burden and does well: it discloses the daily snapshot cadence, the membership rule for the scored tier, ordering by market cap rank, and that absence from a band means unscored rather than Active. It also adds a disclaimer about CoinGraph ratings being opinions. It omits details like pagination, output fields, or rate limits, but provides meaningful behavior beyond the 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?

Three compact sentences with no filler. The first sentence front-loads the operation, scope, and ordering; the second explains band membership; the third clarifies absence semantics and adds a disclaimer. Every sentence earns its place.

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 simple two-parameter list tool, the description covers the core selection and invocation semantics well: what is listed, from what snapshot, in what order, and how band membership is determined. Gaps remain because there is no output schema, so return fields are not described, and the optional limit parameter is never mentioned. These are not fatal, but they keep it from being fully complete.

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 only 50%, since limit has no schema description. The description adds useful meaning to the band parameter by explaining how bands are computed and what absence from a band means, which helps interpret enum values like Active. However, it never addresses the limit parameter or explains the substantive differences between Weakening, Distressed, and Dormant, so the compensation is partial.

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?

Description begins with a specific verb and resource: lists coins by survival band, scoped to today's daily snapshot and ordered by market cap rank. This clearly differentiates it from sibling tools like coingraph_compare, coingraph_diff, and search_coins without needing to open their schemas.

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 makes the intended use easy to infer: call this when you need the coins currently assigned to a survival band. However, it does not explicitly state when to prefer this over related tools like get_survival_rating or search_coins, nor does it mention any exclusions or alternative conditions.

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