corpusAI Cloud Pricing

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description goes beyond that by disclosing cost ("Free"), the anchoring chain (Base, eip155:8453), the daily cadence, the serving path /attest/<day>.json, and a concrete verification workflow including EIP-712 signatures per row — real behavioral context an agent could not get 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?

The critical qualifier ("Free") is front-loaded, followed by the resource, the record shape, and the verification recipe in a tight three-sentence block. Dense with domain jargon (keccak256, EAS UID, EIP-712), but every clause carries information a verifier needs.

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 not be explained. The description still covers what a record contains, how to verify it, where the referenced file lives, and where to read governance, which is everything needed to call a zero-parameter read tool correctly.

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 zero parameters, so there is nothing for the description to disambiguate. The baseline of 4 applies; the description correctly implies a full dump rather than a parameterized query.

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 names a specific resource (daily on-chain attestations) and defines its exact granularity (one record per store day) with the fields each record carries. This cleanly separates it from the sibling fixing tools (index_fixing, tokens_fixing), which expose the fixings themselves rather than their on-chain attestations.

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?

"Free" and the pointer to /governance imply context, and the verification procedure (re-hash the file bytes, compare against fixingsHash) implies the primary use case of independent verification. However, there is no explicit routing such as "use this instead of index_fixing when you need an auditable anchor," so usage is only implied.

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

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

Annotations already declare the safe read-only/idempotent profile, so the description earns credit for adding non-structured traits: per-call cost, sampling cadence, 28-day bucket granularity, and the fact that no history exists before the first sample. These are real behavioral facts an agent needs but cannot read off the annotations.

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 with the cost notice, then the data definition, then granularity and history bounds. Sentences are dense and largely waste-free, though the bucket enumeration is a long aside that slightly thickens already-complete prose.

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?

With an output schema present and rich annotations covering the safety profile, the description needn't explain return structure, and it supplies the remaining context (cost, cadence, data-window limits). It is complete enough to call correctly; only cross-sibling routing is absent.

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% (region, sku, from, to all documented with defaults), so the schema carries parameter meaning and a 3 is the baseline. The description explains bucket ranges, but those describe output values rather than adding syntax or constraints for the four input parameters.

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 specific resource and payload precisely: 'Azure spot eviction-rate history' with 28-day buckets sampled daily. An agent immediately knows what data comes back, though it never names or contrasts any sibling (e.g., spot_daily, spot_history) to disambiguate within a large tool family.

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?

Usage is only implied: you'd call it to inspect Azure eviction history by region/SKU, and it flags the cost (0.01 USDC) and the collection start date as a hard boundary. There is no explicit when-to-use vs. when-to-use-an-alternative guidance, and no exclusions against neighboring tools.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely new context that annotations cannot carry: the call is paid at 0.10 USDC, which affects whether an agent invokes it speculatively. It stops short of describing auth requirements or what a 'stress score' means.

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?

Two short clauses, pricing and subject front-loaded, with zero filler. The cost warning sits first where an agent will see it before deciding to call.

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?

Output schema exists, so return values need not be explained, and the single parameter is fully covered by the schema. However, the central domain concept ('capacity stress score') is left undefined and the crowded capacity sibling set is never disambiguated, leaving the agent to guess which capacity tool answers its question.

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 description coverage is 100% — the single 'day' parameter already documents YYYY-MM-DD format and default-latest behavior. The description only restates the one-day scope, adding no format or edge-case detail beyond the schema, which is the expected baseline.

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?

States a specific resource (every GPU model's capacity stress score), a scope (one day), and an ordering (tightest first), so an agent knows exactly what comes back. It does not distinguish itself from near-named siblings such as capacity_stress, capacity_headline, or capacity_history, which is the only missing piece.

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?

No when-to-use or when-not guidance, and no routing to alternatives despite three closely related capacity siblings. 'For one day' faintly implies this is the daily snapshot rather than history, but that is inference, not guidance.

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

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

Annotations already cover read-only/idempotent/non-destructive/open-world, so the bar is lower, yet the description adds real operational context: results are cached ten minutes, sorted tightest-first, and limited to GPUs with at least two signals. It does not discuss rate limits or freshness beyond the cache window, but the added behavioral detail is substantial.

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 tight sentences with the cost and scope front-loaded, then scoring semantics, then the pointer to paid alternatives. The telegraphic phrasing ('score only', 'tightest first') is efficient rather than padded, though it reads slightly clipped.

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 structure needn't be explained, and the description still supplies everything an agent needs to interpret the result: the 0–100 scale endpoints, sort order, minimum-signal inclusion rule, cache staleness, and where richer detail lives. Nothing material 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 zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. The description correctly spends no space on parameter syntax.

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?

Names a specific resource (capacity stress score per GPU model) with an explicit scope (latest day, score only) and distinguishes itself from the sibling capacity_stress and capacity_board tools by stating that components and inputs live in those paid endpoints. An agent can tell this apart from its siblings without opening a 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?

The leading 'Free.' plus 'score only' and the pointer to the paid /capacity/stress and /capacity/board clearly signals when this tool is the right choice (headline number only, no component detail). It stops short of an explicit 'use this instead of X when' formulation, but the routing condition is readily inferable.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely useful non-annotation context: the call is metered at 0.05 USDC per call, which materially affects how an agent should plan invocations. It stops short of explaining result granularity or limits, so not a 5.

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?

Two short sentences with zero filler, and the cost constraint is front-loaded so the agent sees the billing implication before anything else.

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 needn't be described. Combined with full schema coverage and rich annotations, the description covers scope and cost; the only real omission is the default behavior when from/to are omitted.

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 description coverage is 100% (gpu with an H100 SXM example, from/to as YYYY-MM-DD), so the schema already carries parameter meaning. The description only echoes the single-GPU scoping and adds no date-range or format detail, which is the correct baseline of 3 when the schema does the work.

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?

States a specific resource and scope: 'Daily capacity stress scores for one GPU model.' Combined with the name, an agent knows this returns historical time-series stress data scoped to a single GPU. It does not, however, distinguish itself from near-siblings like capacity_stress, capacity_board, or capacity_headline, which is the only thing keeping it from a 5.

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 no when-to-use guidance: it never says to reach for this instead of capacity_stress (current) or capacity_board, nor does it explain the intent of the from/to range. The pricing note is cost context, not usage routing, so the agent must infer selection from the name alone.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower; the description adds the non-obvious commercial constraint that each call costs 0.01 USDC. It also discloses how the number is derived (mean of components available that day) and names each component's source, which is context the annotations cannot carry.

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?

Front-loads price and the score's meaning before the component breakdown, and every clause carries information an agent would otherwise have to guess. The component formulas are dense but they define the returned number, so they earn their space.

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?

Output schema exists, so return-value explanation is not strictly required, yet the description still supplies the component semantics needed to interpret the score. With pricing, scope, scale, and inputs all covered, only the sibling-routing guidance 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 description coverage is 100% for both parameters (day format, normalized GPU model with example), so the schema does the heavy lifting and the baseline is 3. The description reinforces that the result is scoped to a single gpu/day but adds no format or naming detail beyond the schema.

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?

States a specific resource (capacity stress score), its scale (0 slack to 100 tight), and its exact scope (one GPU model on one day). An agent can distinguish it from capacity_board, capacity_headline, and capacity_history without opening any 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?

The scoping phrase 'for one GPU model on one day' and the per-call price imply when this tool applies, but no alternative sibling (e.g. capacity_board or capacity_history) is named and no when-not condition is given. Usage is inferable rather than instructed.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds value beyond that: it is 'Free' (cost/rate context not in annotations) and it doubles as the legend for `source` values used by /spot/daily and /spot/monthly, which is non-obvious cross-tool behavior.

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?

It is front-loaded with the cost ('Free') and the resource, then the row structure, then the cross-tool usage constraint. Dense but largely earned; the parenthetical lists (instance types, events, first/last event, daily/monthly ranges) are slightly heavy for a single paragraph.

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 not be spelled out, yet the description still orients the agent on how to use the result (region values reused verbatim, sources legend). Given the zero-parameter surface and rich annotations, this is essentially 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?

The tool takes zero parameters, so the baseline is 4. The description has no parameters to clarify and correctly focuses on output content and cross-tool region reuse instead.

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 names the resource (a per-(provider, region) catalog of providers, regions, coverage windows and event counts) and precisely enumerates what each row contains. It also states its unique role relative to siblings: the authoritative source of `region` values and of the `sources` legend for /spot/daily and /spot/monthly.

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?

It clearly tells the agent when to use it — call this first to obtain `region` values, which must be reused verbatim in every other call. It doesn't state explicit exclusions or name sibling alternatives by name, but the directional guidance ('use verbatim in every other call') is concrete and actionable.

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

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

Annotations already declare readOnly, idempotent, non-destructive behavior, yet the description adds substantial extra context: a per-call price (0.05 USDC), the provenance/methodology for aws-spot and gcp-spot rows (time-weighted daily bar divided by GPUs per node per region), and data coverage start dates. This is exactly the value-add expected beyond 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?

Front-loaded with cost, purpose and scope, and every subsequent sentence carries real information (aggregation outputs, spot methodology, date ranges). It runs long, but there is little filler to cut.

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?

With an output schema present, the description need not spell out return values, and it instead supplies the pricing, comparability rationale, and coverage windows an agent needs to call the tool correctly. Nothing material 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 description coverage is 100%, so gpu normalization, date format, and from/to defaults are already fully documented in the schema. The description adds indirect context (one model at a time, data availability windows) but no new parameter-level syntax or constraints, so the baseline 3 applies.

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?

States a specific resource (daily USD/GPU-hour index), scope (one GPU model, per provider and market), and includes the hyperscaler spot legs. It is precise enough that an agent can distinguish it from gpu_quotes or index_history without opening 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 establishes context (paid per call, quote history start dates, spot legs reach further back) but never says when to use this tool versus siblings like gpu_quotes or index_fixing, and gives no explicit exclusions. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds the useful 'Free' fact (no billing) but says nothing about rate limits, auth, or when the snapshot data is refreshed. Adds a little beyond annotations but not much.

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?

Front-loaded with the key qualifier 'Free.' followed by one dense sentence enumerating contents. Every element is informative, though the long field list borders on restating the output schema. No filler or redundancy otherwise.

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?

A read-only, zero-parameter listing tool with an output schema already documented, so return values need no further explanation. The description is complete for correct invocation; the only omission is explicit routing guidance against the many sibling GPU tools.

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 zero input parameters, so the baseline is 4 and no parameter explanation is required. The mention of 'use verbatim as `gpu`' is cross-tool guidance rather than a parameter of this tool, so it neither helps nor hurts.

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?

States a specific resource and scope: a catalog of GPU models with rental quotes, the providers quoting them, quote counts, price floor, and hyperscaler spot-family mappings. This is clearly distinguishable in content from gpu_quotes or gpu_index, though it never says so explicitly. Reads as a clear catalog/listing tool but stops short of naming sibling alternatives.

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?

'Free.' establishes cost context, and 'use verbatim as `gpu`' implicitly tells the agent these names feed other tools' gpu parameter. However, there is no explicit when-to-use-this-vs-gpu_index/gpu_quotes/gpu_snapshot guidance. Usage must be inferred from the content description.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), yet the description adds genuinely new behavior: it is paid (0.01 USDC per call), sources are public price feeds, snapshots are taken several times a day, and Vast.ai contributes only the cheapest 64 offers. Cost and data-freshness context go well beyond the annotations, though rate limits and failure behavior are absent.

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?

Front-loaded with the most decision-relevant facts (paid cost, what it returns). However, the long run-on middle enumerating each output column largely duplicates the existing output schema, which does not earn its place given a structured return definition is already provided.

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 not be re-explained, and the description still fills in cost, cadence, sources, and market semantics for a fairly complex tool. The main gap is the absence of comparative guidance against sibling quote/snapshot tools.

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 description coverage is 100%, so the baseline is 3, but the description adds real meaning the schema lacks by defining the market values (`spot` = interruptible, `bid` = marketplace minimum bid, `secure`/`community` = RunPod tiers). It confirms `gpu` must be a normalized model from /gpu/models, reinforcing rather than merely repeating the schema.

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?

States a specific resource (latest rental quotes) and scope (one GPU model across neo-clouds, marketplaces and other clouds), so the agent knows exactly what it retrieves. However, it never distinguishes itself from close siblings like gpu_snapshot, ondemand, or spot_latest, leaving the agent to infer when this differs from those.

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?

Usage is implied rather than stated: the reader can infer it's for the freshest cross-provider pricing for a single model, and '/gpu/models lists who quotes each model' gives some routing help. But there is no explicit when-to-use or when-not-to-use guidance versus the numerous snapshot and spot siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: the call is paid (0.10 USDC per call) and the result spans all models × providers × markets with hyperscaler spot per region, which tells the agent the cost and the breadth of the fetch. It does not mention caching, freshness, or rate limits.

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?

One tight sentence, with the paid-cost fact front-loaded so the agent sees the price before committing. No filler, though the trailing 'plus hyperscaler spot per region' clause makes the sentence slightly dense.

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?

With an output schema present, the return values need not be spelled out, and with zero parameters and read-only annotations there is little else required. The description supplies the two things the structured fields cannot: the per-call cost and the coverage dimensions of the snapshot.

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 zero parameters, which is the baseline-4 case, and schema description coverage is 100% (vacuously). There is nothing parameter-related the description needs to compensate for.

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 concrete verb+resource: it returns lowest and median USD per GPU-hour across every GPU model × provider × market, plus hyperscaler spot per region. That is more specific than a bare name restatement. However, it never distinguishes itself from close siblings like gpu_index, gpu_quotes, or spot_snapshot, so an agent cannot route confidently between them from the text alone.

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?

There is no when-to-use or when-not-to-use guidance, despite a crowded sibling set of gpu_*, *_snapshot, and spot_* tools. The only selection-relevant signal is the price, which implies 'use sparingly' but does not name an alternative or a condition.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, yet the description still adds real behavioral context: HTTP 200 whenever the server is up, `ready` is false during post-restart ingestion, and paid endpoints return 503 without charging until then. That is useful operational detail beyond the annotations.

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 short sentences with the cost signal ('Free.') front-loaded. The telegraphic fragments ('Liveness and store readiness.') are efficient rather than wasteful, though slightly clipped.

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?

With an output schema present and annotations covering the safety profile, the description needs only to add operational context — which it does by explaining the 200/503 behavior and the `ready` flag. Nothing critical for invoking a zero-parameter health check 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 zero parameters, so the baseline is 4. The description correctly introduces no parameter discussion and instead explains the meaning of the `ready` field the agent will see.

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?

States a specific function clearly: liveness and store readiness check on the service. It is easy to tell apart from data-listing siblings like spot_latest or capacity_board, though it does not distinguish itself from the sibling `status`, which plausibly overlaps in intent.

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 implies when this is useful (checking whether the server and store are up) and explains the practical consequence of `ready` being false for paid endpoints. However, it never explicitly says when to call this versus the sibling `status`, nor does it state any preconditions or exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds genuinely new behavioral context the annotations lack: it is a paid call costing 0.10 USDC and returns a full board in one request. It still says nothing about authentication or rate limits, keeping it short of a 5.

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?

Two short fragments with the cost front-loaded and zero filler. Efficient, though the second fragment is terse enough that a reader must infer the subject (the tool returns the fixings) from the name.

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 low-complexity, single-optional-parameter read tool with an output schema, the description plus annotations cover what an agent needs to invoke it, and the cost disclosure is a useful extra. The main omission is sibling routing, which is scored under usage guidelines.

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 description coverage is 100% and there is only one optional parameter ('day', YYYY-MM-DD, default latest), so the schema already documents it fully. The description adds no format or default detail beyond that, making the baseline 3 appropriate.

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 specific resource and scope: every ticker's fixing for one day, delivered in a single call. The phrase 'every ticker's fixing for one day in one call' implicitly distinguishes it from single-ticker siblings like index_fixing, but it never names them explicitly, so the differentiation is inferred rather than stated.

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?

There is no guidance on when to use this tool versus index_fixing, index_history, or the other index_* siblings, and no stated exclusions. The only context given is the cost, which is pricing, not usage routing.

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

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

Beyond the readOnly/idempotent annotations, the description discloses cost (0.01 USDC per call), the differing default-day semantics for quote segments vs SPOT, and the extra fields SPOT composites carry (per-region values, spread_vs_neo). These are real behavioral traits an agent needs before invoking, not restatements of the annotations.

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 pricing and core output definition are front-loaded, and every clause carries information. It is dense and slightly comma-heavy in the middle, but there is no filler.

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?

With annotations covering safety and an output schema present, the description needn't explain return shapes, and instead covers cost, defaults, and a methodology pointer. The only gap is any explicit routing to or from sibling tools.

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 description coverage is 100%, which sets a baseline of 3. The description adds genuine meaning: the 'day' default is not uniform – it is the latest snapshot for quote segments but yesterday for SPOT – which the schema's 'Default: latest available' does not capture.

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 specific resource and scope: 'One day's fixing for a ticker: median USD per GPU-hour of eligible quotes, with low, high and count.' It also differentiates quote segments (MKT, AGG, NEO, INT, EXE, HYP) from SPOT sources. It is not explicitly contrasted with siblings like index_board or index_history, which keeps it from a 5.

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 explains default-day behavior per source type (latest snapshot vs yesterday for SPOT) and points to /methodology, which is implicit usage guidance. However, it never says when to choose this tool over siblings such as index_board or index_history, so guidance is implied rather than stated.

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

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

Annotations already cover readOnly/idempotent/openWorld, but the description adds a genuinely useful trait they omit: the 0.05 USDC per-call cost and the distinct data-availability windows (quote segments from 2026-09-13, spot series back to 2022-05-31 etc.). This is meaningful behavioral context beyond the annotations.

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?

Front-loads the cost, then purpose, then coverage details. Dense but each clause (price, segment start, spot backfill, per-row source) carries distinct information; the coverage enumeration is slightly list-heavy but 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?

An output schema exists so return structure needn't be explained, and the description covers pricing and data-coverage windows. Complete enough for correct invocation, though it lacks explicit sibling routing.

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 description coverage is 100%, so ticker/from/to are already documented. The description adds only tangential range context (earliest series start) rather than clarifying parameter syntax or formats. Baseline 3 is appropriate.

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?

States a specific verb+resource: 'Daily fixings for a ticker over a date range.' The 'over a date range' phrasing distinguishes it from the single-fixing siblings like index_fixing, though no sibling is named explicitly.

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?

Conveys context (date range, paid per call) that implies when to use it, but never states when to prefer it over index_fixing, index_board, or spot_daily, nor any exclusions. Usage is inferred rather than guided.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description adds one trait beyond them — that the call is 'Free' — and describes the returned content, which is useful but partly duplicated by the existing output schema. No auth, rate-limit, or pagination notes are provided.

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 short sentences, each carrying distinct information: cost, resource contents, identifier format plus examples, and the included membership/methodology data. The most important facts (free, everything) are front-loaded with zero filler.

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?

With no parameters and an output schema already present, the description does not need to enumerate return fields, yet it still explains the ticker grammar and bundled membership lists. The only meaningful gap is that it never says when to prefer this over neighboring index_* tools.

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 defines zero parameters, so no parameter semantics exist to document. The description still clarifies the ticker identifier format, which is the closest thing to an implicit key for consumers. Baseline 4 applies for a no-parameter tool.

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 names a concrete resource (index tickers) and enumerates the payload: each ticker, its segment, definition, segment membership lists, and methodology version. An agent can tell this is a reference/catalog listing rather than a pricing or history feed. It does not, however, explicitly distinguish itself from siblings like index_board, index_fixing, or index_history.

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?

No when-to-use guidance or exclusions are given; the description never points to index_board, index_fixing, or index_history as alternatives. The only contextual cue is the leading word 'Free', which signals a cost consideration but not invocation routing.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: it is free, and it discloses that raw event fields are zero/null for types existing only in the legacy history, which tells the agent how to interpret sparse results.

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?

Front-loaded with the key fact ('Free. Instance types available in a region.') and compact overall. The middle sentence is dense with parenthetical field lists, which is functional but slightly heavy for one breath.

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 not be explained, yet the description usefully describes the shape of the coverage fields. Parameters are covered by the schema and safety by annotations; the only real gap is the absence of alternative-tool routing.

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 description coverage is 100% and all three parameters (provider, region, prefix) are documented in the schema, so the baseline is 3. The description's 'c5.' / 'n2-' prefix examples add a small amount of illustrative value but nothing the case-sensitive prefix schema note doesn't already cover.

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?

States a concrete verb and resource ('Instance types available in a region') with a clear scope, and names the distinguishing payload fields (events/history ranges). It does not explicitly differentiate itself from siblings such as gpu_models or term_instance, so it falls short of a 5.

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 leading 'Free.' signals cost and the prefix note implies a narrowing use case, but there is no explicit when-to-use vs. alternatives guidance and no named sibling to route to. Usage is only implied.

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

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

Annotations already declare it as a safe read (readOnly, idempotent, non-destructive), but the description adds costly context the agent otherwise could not know: 0.01 USDC per call, the exact source API per provider (AWS Price List API, Azure Retail Prices API, TITANS-era for GCP), refresh frequencies, and coverage start dates. This is genuinely additive behavioral disclosure.

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?

Front-loaded with cost and purpose, then organized by provider in parallel structure; nearly every clause carries information (price, cadence, provenance, coverage window). It is dense, and the provider block reads as a semi-colon-heavy run-on, but nothing is wasted.

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 3-parameter, single-entity price-history call with an output schema already covering return shape, the description supplies everything else an agent needs: per-call cost, data provenance, freshness, and time coverage per provider. Nothing material 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 description coverage is 100% and all three parameters carry slugs, examples, and enum values, so the schema does the heavy lifting. The description adds no parameter-level syntax or format detail beyond what the schema already documents, so the baseline 3 applies.

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?

States a precise verb+resource+scope: 'On-demand list-price history of one instance type,' plus the concrete shape of the result ('one row per day the on-demand hourly list price changed; `current` is the price in force'). The word 'history' plus the change-point framing clearly sets it apart from the snapshot-style sibling ondemand_snapshot.

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?

No explicit 'use X instead' routing to a sibling, but provider-specific coverage windows act as real when/when-not guidance: GCP is limited to the TITANS-era series (2024 to 2026-08) and 'not refreshed,' so an agent knows this tool cannot answer current GCP price questions. AWS weekly and Azure daily refresh cadences further bound appropriate use.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds the important behavioral trait that the call is paid (0.10 USDC per call), which is not covered by annotations, though payment mechanics and rate limits remain unspecified.

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?

Two short sentences, front-loading the paid cost followed by the exact purpose. No wasted words and the key information is immediately visible.

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 read-only snapshot with an output schema and rich annotations, the description covers purpose and cost adequately. The main gap is sibling routing among the many pricing snapshot tools, which keeps 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 description coverage is 100% and both required parameters are fully documented in the schema. The description adds no syntax, enum, or format details beyond what the schema already provides, so baseline 3 applies.

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?

States a specific resource (current on-demand list price) and scope (every instance type in a region). Clear what it returns, but does not differentiate itself from sibling pricing tools such as ondemand, reserved_snapshot, or spot_snapshot.

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?

No guidance on when to use this tool versus alternatives like ondemand or reserved_snapshot. The paid cost is stated, but there are no prerequisites, exclusions, or routing cues for an agent choosing among many siblings.

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

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

Annotations already cover read-only/idempotent/non-destructive, and the description goes well beyond them: paid-per-call pricing, data provenance (AWS Price List API, Azure Retail Prices API, GCP Cloud Billing Catalog), refresh cadence (weekly/daily), coverage start dates, and the amortization semantics of the returned values.

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?

Front-loaded with the cost notice and purpose, and every sentence carries substantive content (provenance, cadence, semantics). It is dense and the long parenthetical enumerations of ri_type tokens and provider dates require careful reading, but little is wasted.

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 complex multi-provider time-series tool, the description supplies the provenance, refresh cadence, coverage windows, and value semantics needed to trust and call it, while the output schema handles the return shape.

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% so the baseline is 3, but the description adds real meaning: it maps each ri_type token to its provider-specific meaning (AWS 1y/3y no-upfront/all-upfront, GCP cud_1y/cud_3y), documents region slug conventions per provider, and states the AWS scope (Linux, shared tenancy) that the schema does not.

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?

States a specific verb+resource ('reserved / reservation price history of one instance type') with the data model (change-point series per ri_type, amortized effective hourly USD). It is clearly separable from snapshot-style siblings like reserved_snapshot and ondemand_snapshot by the 'history' scope and series framing.

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 scope is implied (one instance type, one of six ri_type series), and the 0.01 USDC-per-call cost warns about usage, but there is no explicit when-to-use vs alternatives guidance and no sibling (e.g. reserved_snapshot, term) is named as the alternative.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the description's main value-add is the explicit cost disclosure (0.10 USDC per call), which is genuinely useful behavioral context absent from structured fields. It does not add anything about response shape or rate limits, but the paid-call warning is the important bit here.

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?

Two tight sentences with the cost warning front-loaded and the resource description immediately after. No filler, no repetition of schema fields.

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 not be explained, and annotations cover the safety profile. The gap is the '(AWS or Azure)' scope claim, which contradicts the schema's gcp enum value and could cause an agent to skip valid GCP calls, plus no routing guidance among the many snapshot siblings.

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%, so region and provider are fully documented in the schema and the baseline is 3. The description adds no format detail, and it introduces a mild inconsistency by saying '(AWS or Azure)' while the schema's provider enum also allows gcp.

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 names the specific resource (reserved effective hourly price) and scope (every instance type and ri_type in a region), so an agent can tell what it returns. However, it never differentiates itself from the sibling `reserved` or from the other snapshot tools (ondemand_snapshot, spot_snapshot, gpu_snapshot), leaving sibling selection to inference.

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?

There is no statement of when to use this tool versus `reserved`, `ondemand_snapshot`, or `spot_snapshot`, nor any prerequisites or exclusions. The only usage-adjacent signal is the pricing note, which is not guidance about selection.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, but the description adds substantial non-structured behavior: a paid per-call cost, data provenance per era (`source` = pauley/titans/direct), which fields are null when the source only has an average, and that `avg` equals the public dashboard value. This is exactly the kind of context annotations cannot carry.

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?

Front-loaded with purpose and price, then the window/schema semantics. Dense but well organized. The era-by-era detail is arguably heavier than needed for tool selection, though it earns its place for interpreting nullable OHLC values.

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?

With a good schema and an output schema present, the description need not explain return shapes. It covers cost, granularity, provenance, and null handling, leaving no material gap for correct invocation.

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 description coverage is 100%, so the schema already documents from/to/region/instance/provider with examples and defaults. The description adds provenance semantics for the rows returned but no additional parameter syntax, format, or constraint detail beyond what the schema supplies.

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?

States a specific verb (retrieve), resource (spot daily history), and scope (one instance type, all eras stitched, one row per UTC day). An agent can distinguish it from spot_hourly/spot_monthly/spot_latest purely on the stated granularity and coverage.

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 implies usage context (full daily history, all eras stitched) and discloses a per-call fee (0.05 USDC), which helps an agent decide whether to call it. However, it never explicitly says when to prefer this over spot_monthly, spot_hourly, or spot_latest, nor does it state prerequisites for the provider/region/instance trio.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, yet the description still adds material context: the 0.01 USDC per-call cost, the default dropping of repeated identical prices and how include_repeats overrides it. It does not, however, describe rate limits or auth requirements.

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?

Four tight sentences that lead with the paid cost and resource, then behavior, then pagination. Every sentence carries information; nothing is padded, though the pricing tag is slightly awkwardly front-loaded as an aside.

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 not be explained, and the description still covers the cost, the dedup default, and the pagination continuation rule — the details an agent most needs for this event-stream tool. Nothing essential 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%, so the baseline is 3, but the description adds meaning beyond the schema by tying include_repeats to the dedup behavior and explaining the pagination contract (limit rows, truncated, continue with from = next_from) referencing output fields not present in the input schema.

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 specific verb+resource: it returns raw spot price-change events for one instance type, with per-event timestamp, AZ and product. This implicitly distinguishes it from aggregated siblings like spot_daily, spot_hourly and spot_latest via the word 'raw' and 'every price change', though no sibling is named explicitly.

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?

Usage is implied rather than stated: 'Raw spot price-change events' suggests use when event-level granularity is needed, framing it against aggregated siblings. But there is no explicit when-to-use/when-not or named alternative, and the dedup default is the closest thing to a condition.

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

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

Annotations already declare read-only, idempotent, non-destructive, and open-world behavior, so the bar is lower. The description adds valuable context beyond annotations: a per-call cost (0.01 USDC), time-weighting semantics, the cross-zone aggregation rules for open/close/avg/high/low, and a hard 366-day window cap.

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 four sentences are dense but each earns its place: pricing, resource definition, aggregation logic, and window cap. The aggregation sentence is long but necessary for interpreting the OHLC bars correctly.

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?

With a full output schema and rich parameter descriptions, return values need not be explained. The description is nearly complete, covering cost, semantics, and limits, though it does not explain pagination or output ordering if any.

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 description coverage is 100%, so the baseline is 3. The description adds a meaningful constraint beyond the schema by disclosing the 366-day maximum window, which directly affects the `from` and `to` parameters and is not stated in the schema.

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?

States a specific resource and granularity: 'Hourly time-weighted OHLC bars for one instance type.' The word 'Hourly' implicitly distinguishes it from siblings like spot_daily and spot_monthly, but it does not explicitly name or compare against those alternatives.

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?

No explicit guidance on when to choose this tool over spot_daily, spot_monthly, spot_latest, or spot_snapshot. The hourly granularity implies a use case, but the description never states when hourly bars are appropriate or what alternatives exist.

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

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

Annotations already cover read-only/idempotent/non-destructive, and the description adds genuinely new context: a per-call charge (0.01 USDC) and the staleness/retirement semantics of the returned data. It stops short of describing pagination or response shape, but the cost disclosure and freshness caveats are material behavioral context.

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?

Front-loads cost and the core definition, then freshness caveats, then the routing pointer to the sibling. Every sentence is substantive, though the provider-specific retirement aside is slightly dense and could be tightened.

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 not be explained; the description still covers cost, what each record represents, freshness interpretation, and the alternative tool. An agent has everything needed to call it correctly.

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 description coverage is 100% and all three params (provider, region, instance) are documented in the schema with examples and an enum. The description adds no parameter-level detail beyond what the schema provides, so the baseline of 3 applies.

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?

Specific verb+resource: it returns the currently-in-force spot price per (zone, product) for a single instance type, described as the most recent event of each series. It explicitly names the sibling it is not (/spot/snapshot) so the agent can distinguish them without opening 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?

Gives an explicit alternative and the condition that selects it: 'For every type in a region at once use /spot/snapshot.' It also tells the agent how to interpret stale timestamps per provider (AWS ~10 days likely retired, GCP/Azure rarely reprice), which is when-to-trust guidance a caller needs.

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

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

Annotations already establish readOnly/idempotent/non-destructive, and the description goes well beyond them: it discloses a per-call charge (0.05 USDC), that `archive` is default-on, that archive rows are returned separately 'so it never silently blends into the curated series', and that archive provenance is 'third-party, mixes OS products, partly unverified'. These are exactly the caveats an agent needs before relying on or billing for the result.

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?

Every clause carries information — no filler — and the core purpose is stated early. However, the single dense paragraph with heavily nested parentheses (rollup rules, source attributions, date ranges) is hard to scan and buries the archive caveat mid-sentence rather than structuring it as separate points.

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 paid, read-only history tool with an output schema, the description is complete: it covers cost, the two data series and their provenance, rollup semantics, defaults, and the archive/curated separation. Since an output schema exists it did not need to explain return shape, and it still usefully characterizes what the returned series mean.

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%, so the baseline is 3, but the description adds real meaning: it defines the derived fields (`avg` = median of daily averages, open/close from first/last day, `days`, `source`) and explains that `archive` maps to `include_archive` defaulting on with a specific date span (2014-02 to 2023-12) and type count (51). That is value beyond the schema's terse boolean description.

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?

States a specific verb and resource with scope: 'Full monthly history for one instance type, back to 2014 for legacy AWS types.' The monthly granularity plus the explicit statement of what `months` and `archive` contain makes it distinguishable from siblings like spot_daily, spot_hourly, and spot_latest without opening any 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?

Usage is only implied by the granularity ('monthly history'), which lets an agent infer this is the monthly-resolution sibling, but no alternative is ever named (spot_daily, spot_hourly, spot_latest are never referenced) and no when-not-to-use condition is given. The cost note ('Paid, 0.05 USDC per call') is useful context for choosing whether to call, but it is not routing guidance.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds meaningfully beyond that: an explicit price (0.10 USDC per call), an expected result size (~6,000 rows for an AWS region), and per-row timestamp/age contents.

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?

Front-loads the cost and then explains the payload, bulk size, and pricing rationale in four tight sentences. There is slight redundancy between the 'current price of every instance type' line and the 'bulk snapshot' line, but no wasted padding.

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 two-parameter read tool with an output schema and full annotation coverage, the description supplies everything an agent needs: cost, scope, result volume, and semantic equivalence to /spot/latest. Nothing material 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 description coverage is 100%, so both the region slug formats and the provider enum are already fully documented in the schema. The description adds no syntax or format detail beyond what the structured fields provide, so the baseline 3 applies.

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?

Specific verb+resource: returns the current price of every instance type, zone and product in an entire region in one call. It also names the sibling it mirrors ('same semantics as /spot/latest') and contrasts with per-series tools, so an agent can distinguish it from the other spot_* 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?

It implies the usage context ('bulk snapshot', 'one call returns the entire current price surface') and notes it's priced higher, which hints at when it's worth it over targeted tools. However, it never explicitly states when to prefer it over spot_latest, spot_daily or spot_hourly, leaving the choice to inference.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new context: it is free of charge and it reads from public URLs, which the annotations do not convey.

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 short sentences: cost, contents, and use case. The cost fact is front-loaded and every sentence carries information with no padding.

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 not be explained, yet the description still summarizes the payload usefully. Combined with the free-cost note, the timing advice, and the annotation-backed safety profile, an agent has what it needs; only explicit routing to sibling freshness/snapshot tools is absent.

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, so the baseline is 4. The description does not need to add param meaning, and it correctly adds none.

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 specific resource (freshness of every data source) and enumerates the returned fields per source: last successful snapshot/event, staleness in days, and public URL. This distinguishes it from per-source siblings like spot_latest or gpu_snapshot by covering all sources, though it never names an alternative explicitly.

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?

"Use it to decide whether a fixing or quote is current before paying for it" gives a concrete precondition for invocation. It stops short of naming alternatives (e.g., when to prefer attestations or a specific snapshot tool), so it is clear context without exclusions.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds genuinely new behavioral context: a per-call cost of 0.05 USDC, the aggregation methodology (median across regions, divided by GPUs per node, with lo/hi and discount-to-on-demand), and an explicit data exclusion.

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?

Front-loads the cost and the core output, then methodology, then exclusions — every sentence carries information. The middle sentence is long and comma-heavy, but nothing is filler.

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; the description instead supplies the aggregation semantics, the pricing unit, and the excluded data needed to interpret results correctly. Nothing an agent needs to call or interpret this tool 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?

With one parameter and 100% schema description coverage, the schema already documents that gpu is a normalized model with a hyperscaler mapping and gives examples. The description adds only that the mapping is a prerequisite via /gpu/models hyperscaler_spot_legs, so baseline 3 is appropriate.

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?

States a specific verb (returns term structure) and resource (per-hyperscaler GPU pricing) plus the exact term buckets (spot, on-demand, 1y, 3y) and unit (USD per GPU-hour). An agent can distinguish it from siblings like ondemand, reserved, and spot_latest without opening any 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?

The framing question 'what does a committed H100 cost against spot and on-demand, per cloud' gives clear context for when to reach for this tool, and it names an exclusion (neo-cloud commitment prices are quote-only and excluded). It stops short of explicitly routing to sibling alternatives like term_instance or reserved.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description earns credit for going further: it discloses the per-call cost (0.01 USDC), the data provenance (spot median across zones, only where spot events exist), and the amortization semantics of reserved terms. That is real behavioral context an agent needs before spending on this call.

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 paid-call notice is front-loaded, and the rest is dense, information-bearing prose with no filler. The provider-term breakdown is long but each clause carries domain detail; only mild density costs it a point.

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?

With an output schema present, the description need not restate return values, yet it usefully explains the non-obvious `discount_pct` basis and the provider-specific committed-use term universe (AWS 4, Azure 2, GCP 2). For a pricing lookup tool this covers everything an agent needs to interpret results correctly.

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 description coverage is 100%, so all three parameters (provider, region, instance) are already fully documented with formats and examples. The description adds no param-level detail beyond the schema; the `discount_pct` explanation concerns a returned field, not an input. Baseline 3 applies.

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 names the specific resource (price ladder for one instance type) and enumerates exactly what the ladder contains: spot, on-demand, 1y/3y reserved terms. An agent can tell it retrieves pricing for a single instance. It does not explicitly distinguish itself from the closely-named sibling `term`, which is the only real gap.

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?

Usage is implied rather than stated: the tool returns prices for one instance type, and the 0.01 USDC per-call cost signals it is a metered lookup. There is no explicit when-to-use vs. alternatives guidance (e.g., how it relates to `spot_latest`, `ondemand`, or `reserved`), leaving the agent to infer routing.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world). The description adds genuinely useful context beyond them: the 0.10 USDC per-call cost, which is critical for an agent deciding whether to invoke, plus the daily snapshot scope and frontier basket inclusion.

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?

Two tightly packed sentences with no wasted words, and the cost is front-loaded so an agent sees the paid nature immediately. The phrasing is terse to the point of being cryptic ('blended fixing', 'frontier basket').

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?

With annotations carrying the safety profile and an output schema present, the description only needs to convey scope and cost, which it does. The main gap is lack of routing against the numerous sibling tokens_* tools, but nothing essential to invocation 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 the single optional 'day' parameter already documents the YYYY-MM-DD format and default. The description's 'for one day' reinforces the semantics but adds no format or edge-case detail beyond the schema, so the baseline 3 applies.

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 specific resource ('Every model's input, output and blended fixing for one day, plus the frontier basket') with an implicit fetch verb. It is distinguishable from tokens_history (time series) via the 'for one day' scope, though the terms 'blended fixing' and 'frontier basket' are jargon-heavy and the sibling tokens_fixing is not explicitly contrasted.

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?

There is no explicit when-to-use guidance and no alternatives named among the many tokens_* siblings (tokens_fixing, tokens_history, tokens_models, tokens_quotes). The scope 'for one day' weakly implies a daily snapshot rather than history, but the agent must infer this.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, and the description goes further by disclosing the 0.01 USDC per-call cost, the median-across-sources aggregation method, and the standard-tier exclusion of batch/free variants. It stops short of noting wallet/auth requirements or any rate limits, but the cost and methodology disclosure is meaningful extra context.

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 cost and core operation are front-loaded, followed by the ticker grammar, with no filler sentences; every clause carries specification the agent needs. It is dense with notation but not redundant.

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 supplies the ticker vocabulary, aggregation semantics, tier restriction, and price. The one missing piece is sibling routing (when this fixing beats tokens_board/tokens_quotes), which is the only gap for an otherwise self-contained definition.

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 description coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema by defining the units of `.IN`/`.OUT` (USD per million tokens), giving the exact `.BLEND` formula (3·input + output) / 4, and explaining that `CX.TOK.FRONTIER.<side>` is a median over the frontier basket from /tokens/models.

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 specific verb and resource ('One day's token price fixing for a ticker') and even gives a concrete ticker example, so the agent knows exactly what is being computed. It does not explicitly distinguish itself from the many pricing siblings (tokens_board, tokens_history, tokens_quotes), leaving that differentiation to inference.

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?

Usage is only implied: a single-day fixing keyed by ticker, with batch and free tiers excluded. There is no explicit statement of when to reach for this instead of tokens_board/tokens_history/tokens_quotes, nor any when-not guidance, so the agent must infer the routing.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds two genuinely useful behavioral facts the annotations do not: the per-call cost and the earliest available data date. Auth requirements and any rate limits remain unstated.

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?

Two short sentences with zero filler; the cost disclosure is front-loaded before the data description. Every clause carries information.

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. Cost, granularity and data start are covered; only the behavior of the from/to range (defaults, maximum span) is left implicit.

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 description coverage is 100%, so the schema already documents ticker, from and to formats. The description's phrase 'daily fixings' adds granularity meaning and the snapshot date gives context for the from range, but no syntax or default-range behavior is supplied beyond the schema baseline.

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?

States a specific resource (daily fixings for a token ticker) and scope (from the first snapshot 2026-09-14), so the agent knows it returns a historical series. It does not explicitly contrast with sibling tokens_fixing or tokens_board, so an agent must infer that history differs from a point-in-time fixing.

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 pricing disclosure (0.05 USDC per call) gives a cost/usage signal, and the start date implies historical lookups. However, it never states when to choose this over tokens_fixing, tokens_board, or tokens_quotes, leaving the alternative-selection guidance to inference.

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

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

Annotations already cover readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully declared. The description adds useful context beyond that: the data is free, it is a daily snapshot ('today's price range'), and it includes provenance counts (how many sources and hosts list each model). It does not discuss caching or refresh behavior, but the remaining gaps are minor.

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?

Front-loaded with 'Free.' and then a single dense sentence enumerating the returned fields, followed by a short note about the frontier basket. No filler, though the middle sentence is long and comma-heavy, which slightly reduces scannability.

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?

With an output schema present, the description need not document return structure, yet it does so helpfully; combined with the read-only annotations and zero parameters, an agent has enough to invoke it correctly. The main omission is any indication of which sibling tool to use for other token-price needs.

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 (0 params, no required fields), so the baseline is 4. The description correctly implies a parameterless bulk listing rather than a filtered query, which is consistent with the empty schema.

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 what the tool returns: canonical model slugs, ticker codes, source/host counts, and today's min/max input/output prices, plus the frontier basket. It is unambiguous what resource is being listed. However, it never distinguishes itself from close siblings like tokens_board, tokens_fixing, tokens_quotes, or tokens_history, which all deal with the same token-price domain.

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?

There is no when-to-use or when-not-to-use guidance, and no alternative is named. 'Free' hints that cost is not a concern but gives no routing logic. An agent must infer from the name alone whether this is the model catalog versus the board/fixing/quotes siblings.

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

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

Goes well beyond the readOnly/idempotent annotations by disclosing the per-call charge (0.01 USDC), the exact source set (OpenRouter catalog and per-host endpoints, LiteLLM, DeepInfra), and what each row contains (cache-read price, context length, extra.variant for batch tiers). This is the kind of context annotations cannot carry.

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?

Two dense but front-loaded sentences: cost first, then scope, then source list and row contents. No filler clauses; every phrase conveys a distinct fact.

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?

With an output schema present, return shape need not be explained, yet the description still summarizes row content and source coverage, and adds the payment requirement. Nothing needed 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%, so both parameters are already documented (day defaulting to latest, model slug referencing /tokens/models). The description restates the one-model-one-day semantics but adds no format or syntax detail beyond the schema, so baseline 3 applies.

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?

States a specific verb+resource+scope: 'Every listed price for one model on one day' across named sources. An agent can immediately tell this apart from the index-fixing or board siblings because it's the per-model, per-day quote lookup.

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?

Usage is implied by the description (fetch quotes for a given model/day) and the 0.01 USDC cost signals it is a deliberate paid lookup, but there is no explicit when-to-use or when-not-to-use guidance and no named alternative (e.g. tokens_history vs tokens_fixing).

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