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

Annotations only cover read-only/idempotent/open-world; the description adds genuinely non-obvious behavior: deterministic rule evaluation (same numbers, same verdict), failed sources degrading confidence and being named under 'missing' rather than zero-filled, and 'fragile' meaning crowded positioning plus cheap implied volatility. These are exactly the traits an agent could not infer from structured fields.

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 sentence and the SCOPE sentence cleanly closes it out. It runs long for a two-parameter tool, with some rhetorical padding ('argued with rather than taken on faith') and slight redundancy between 'DETERMINISTIC, not a model opinion' and 'the same numbers always give the same verdict'.

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 explanation, and the description still previews the shape of the verdict and its drivers. For an optional-two-param read tool with full annotations, nothing an agent needs in order to call it correctly is missing.

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% and both params are documented there, so the baseline is 3. The description adds real meaning on top: the coin param is tied to the BTC-only percentile rule ('for other coins the level is reported without the crowded label'), and sizeUsd is framed as the trade size at which execution cost is measured.

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?

Concrete verb-plus-resource: it composes positioning, sentiment, implied volatility, macro regime and execution cost into a single stance (risk-on/risk-off/fragile/neutral) with confidence, drivers and invalidators. It also draws an explicit line against the model-based multi-asset analysis, so an agent can separate it from analyze_market without opening either schema.

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?

Both the when and the when-not are stated: 'SCOPE: one coin, one fixed set of rules, this one report' versus a differently-worded question or several assets weighed against each other, which is a separate PAID analysis. The free-versus-paid boundary and the BTC-only percentile caveat are also spelled out.

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