Historical context for any recorded metric (conditional distribution)

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

The description goes well beyond the annotations by disclosing key behavioral traits: buckets under 30 days are suppressed, most metrics do not separate from the base rate, and the interpretation says so plainly. It also specifies the concrete outputs (median forward BTC return and up-share at +1/+3/+7 days with the all-days base rate), which is valuable given there is no output 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?

The description is front-loaded with the primary use case, then delivers mechanics, honesty rules, and the supported metric list in a compact sequence. Every sentence adds decision-relevant information, and the length is justified by the need to convey conditional-distribution behavior and interpretation caveats.

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 single-parameter read-only tool with no output schema, the description is complete: it explains what the tool returns, how the bucketing works, the interpretation caveat, and the supported metric candidates. Nothing essential is left for the agent to infer.

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 input schema already fully documents the single `metric` parameter with examples and a pattern, so the baseline is 3. The description adds extra semantic value by enumerating the full supported metric set and clarifying that the metric must be a 'recorded metric' with daily history, which helps the agent pick valid inputs.

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 states a precise trigger condition and resource: it explains the tool buckets a metric's current value against its own daily history to determine whether readings are high or low and what happened after similar readings. It clearly differentiates itself from a forecast and lists the exact metrics it supports, making its purpose unambiguous even among many sibling tools.

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 gives an explicit 'Call this when...' condition: when the user asks whether a metric reading is high or low, or what happened after similar readings. It also states 'History, not a forecast,' which is a useful exclusion. It does not name alternative tools, but no sibling tool appears to overlap directly, so the lack of explicit alternatives is not a significant gap.

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