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

Annotations already declare all safety hints (readOnly, idempotent, non-destructive), so the bar is lower. The description adds crucial behavioral details: the cost (0.01 USDC per call), the segment-dependent default day, and the fact that SPOT composites carry per-region values and spread_vs_neo. It also points to /methodology for eligibility, making the tool's behavior and limitations transparent.

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 three sentences, front-loaded with the cost and core return value, then explains segment variations and points to methodology. Every sentence earns its place with no redundancy or fluff.

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 2-parameter tool with no output schema, the description covers the essential behavior: return fields, default day semantics, segment differences, and reference to methodology. The only minor gap is that it doesn't explicitly state the exact JSON structure of the response, but since no output schema exists and the fields are named, this is acceptable. The completeness is strong for the complexity level.

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 already documents both parameters with descriptions (100% coverage), giving a baseline of 3. The description adds meaningful nuance: it clarifies that the 'day' default is not universally 'latest available' but depends on whether the ticker is a quote segment or SPOT, and it explains the output fields (median, low, high, count) that are implied by the parameters. This goes beyond the schema's static default text.

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 clearly states this tool returns one day's fixing data (median USD per GPU-hour, low, high, count) for a given ticker. It distinguishes itself from siblings by explicitly describing the segment-specific behavior (MKT/NEO/INT/HYP vs SPOT) and the meaning of composite values, making it unmistakable what this tool does.

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 provides strong context on when to use the tool by explaining the default day logic (latest snapshot for quote segments, yesterday for SPOT) and referencing the full methodology. It does not explicitly mention alternates like index_history or spot_daily, but the segment and composite details give enough clue that this is the tool for daily fixings, making the usage intent clear even without direct sibling exclusion.

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