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

Annotations already declare read-only, idempotent, non-destructive, open-world, so the safety bar is low; the description nonetheless adds substantive behavior: one shared quote per minute across tools so numbers reconcile, and the warning that the price history may end a few days before today even though the spot price is live. It also pre-empts a likely misreading by stating the band share is a count of past days, not odds.

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?

Content is front-loaded and every clause carries information, but the first sentence is a single ~90-word run-on enumerating nine outputs, which makes it hard to scan. A bulleted or sentence-per-output structure would serve the agent better without losing content.

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?

There is no output schema, so the description must carry the return contract — and it does, naming every field, the definition of the regression line (log fit over all daily closes since 2010), the quote timestamp basis, and the data-freshness caveat. Nothing an agent needs to interpret the response 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?

The tool takes no parameters (empty schema, 100% coverage), so the baseline is 4; the description earns the extra point by fully specifying the returned fields instead, which is the only semantic surface left to document.

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 verb and resource — where bitcoin's price sits on the rainbow chart right now — and then enumerates exactly what is returned (band name, band number, dollar range, distance from line, historical share, chart link, regression fit). It is clearly separable from rainbow_history (past) and simulate_dca (which it explicitly says its quote reconciles with).

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 'right now / today' framing implicitly routes the agent away from rainbow_history, and the closing sentence sets an explicit behavioral boundary: descriptive only, no buy/sell advice, no price prediction. It also flags a reconciliation relationship with simulate_dca. What is missing is an explicit statement of when to prefer this over rainbow_history or cycle_check.

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