Rack Rates

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

Annotations already declare this to be a non-destructive, idempotent, closed-world read, so the description isn't carrying the safety burden. It still adds real context beyond the annotations: filtering to "active" SKUs only, the ranking being pure list price with no sponsorship/affiliate weighting, and that rows expose verified_at, stale and source_url so the agent knows freshness is surfaced.

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 purpose and ranking rule in the first clause, then packs the spec dimensions into a compact semicolon list. Dense but every clause carries information; slightly over-packed relative to a clean two-sentence structure.

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 10-parameter tool with no output schema, the description covers the ranking semantics, the freshness fields returned (verified_at, stale, source_url), and the key filters. It leaves out how stale rows are treated, the provider restriction and how limit/ordering behaves, but nothing essential to a first correct call 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 schema already documents all ten parameters, making 3 the baseline. The description reinforces that vcpu/ram_gb/disk_gb are minimums rather than exact matches and that region 'eu' means EU-deployable, but it omits the limit, provider and gpu_count parameters entirely.

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: rank cheapest active SKUs that satisfy a minimum spec, with the ranking rule (list price only, no sponsorship/affiliate weighting) made explicit. It implies a distinction from search_skus and get_price but never names them or contrasts the use cases directly.

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?

"Cheapest active SKUs meeting a minimum spec" implies the use case (find the lowest-priced option for a requirement), but there is no explicit when-to-use guidance, no mention of when to prefer search_skus or estimate_cost instead, and no prerequisites 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 read-only, idempotent, non-destructive and closed-world, and the description adds real context on top: what comes back (line items, the rates used, native/USD/EUR totals, verified_at, source_url) plus the VAT caveat. With no output schema, that return-format disclosure is valuable; only the failure mode for an unknown sku_id is left 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?

Front-loaded with the purpose, followed by return contents and then a single caveat clause. Dense but every clause carries information an agent cannot get from the schema or annotations.

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?

Given six parameters, no output schema and full annotation coverage, the description supplies the missing pieces: return shape, currencies, price provenance fields and tax scope. Only error behavior and the zero-default semantics are unaddressed.

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 every parameter is already documented, including which ones apply to LLM versus instance SKUs. The description restates the same token/hours/months grouping without adding format, bounds or interaction rules, so the baseline 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 and resource: itemised cost of a usage profile at a SKU's current list price, and even specifies the units of measure per SKU family. It does not name a sibling, so an agent must infer the boundary against get_price or cheapest_for_spec.

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 — it is a calculation on an already-known sku_id, and 'pure arithmetic on stored prices' hints it is not a price lookup. But there is no explicit 'use get_price to fetch the rate' or 'use cheapest_for_spec to choose a SKU' 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/closed-world, and the description goes beyond them by disclosing the default 90-day window, the row semantics (change points, not daily samples), the currency/FX payload, and error behavior for an unknown id. Missing only things like ordering or row-count 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?

Three tight sentences with the resource and window front-loaded, then the row semantics, then the error case. No filler or repetition of the title.

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 output schema, the description carries return-shape disclosure and does it well by explaining what each row represents plus the error object. Ordering of rows and any result-size limits are the only notable omissions.

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 already documents days (1–3650, default 90) and sku_id's origin in search_skus, so the description mainly restates the default. Its only added value is tying days to a look-back window interpretation of the returned change points.

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 (price change points of a SKU) and scope (last N days), and the clarification 'rows are change points, not daily samples' implicitly separates it from get_price/get_index. It never names a sibling, so an agent must infer the routing rather than read it.

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 change-point framing, and the schema links sku_id to search_skus, but the description gives no explicit 'use this instead of get_price when...' guidance or exclusions. An agent can guess when to call it, but nothing is 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?

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description's own contribution is the disclosure that constituents are returned so the value can be recomputed — useful, since there is no output schema — but it says nothing about how the days window changes what is returned or about result size/pagination when listing all series.

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 sentences, no filler, with the return contents stated before the list-all variant. The first sentence is long and front-loads examples ahead of the core behavior, 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?

With no output schema, the description carries the burden of describing returns and does so (latest value, constituent count, constituents). Both parameters are covered by the schema, leaving only minor gaps around how the look-back window affects the returned value.

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 both parameters, making 3 the baseline. The example slugs (eu-vps-2vcpu-4gb-floor, frontier-token-input-floor) do add domain meaning about slug format, but the description says nothing about the days window or its interaction with the series value.

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 (a named daily index series) plus exactly what comes back — latest value, constituent count, and constituents — so an agent knows this returns data it can verify. It never names a sibling (get_price, get_history), so the boundary against those tools has to be inferred from domain knowledge.

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?

"Omit series to list all series with their latest values" explicitly documents the two call modes and the condition that selects each. It gives clear usage context but no exclusions or routing advice versus get_history/get_price, so it stops short of a 5.

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, but the description adds real behavioral detail beyond them: the stale flag semantics (true when the latest fetch failed and the price is the last verified one) and the error-object response for unknown ids. It stops short of noting caching or freshness windows, which would have made it 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?

One dense, front-loaded sentence that leads with what is returned and only then qualifies with the stale/error cases. Nothing is wasted, though the parenthetical example list makes it longer than strictly necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description compensates by enumerating the returned fields (secondary prices, USD/EUR equivalents, spec, source URL, verified_at, stale flag, other listings) and the error case. That is everything an agent needs to call and interpret this single-parameter read tool.

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 schema already documents sku_id with an example. The description supplies additional example id formats (vps/ovhcloud/..., llm/anthropic/...), but that largely restates the schema's format hint, 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 verb and resource (current list price of one SKU) plus the exact granularity, and the mention of 'other listings of the same model' and 'stale flag' clearly distinguishes it from get_history (historical) and search_skus (discovery). An agent can pick it out of the sibling set without opening the 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?

Implicit usage: it clearly takes an id 'as returned by search_skus' and covers the unknown-id error case, but it never explicitly says when to prefer get_history, cheapest_for_spec, or estimate_cost. The agent must infer the current-vs-historical boundary from the word 'current'.

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, non-destructive, closed-world behavior, so the description's added value is the row-level contract: newest-first ordering, first-seen timestamp, the previous good snapshot as the comparison baseline, and the source id. That is real context an agent cannot get from annotations. It stops short of covering pagination/cursor behavior or result-size limits implied by 'limit'.

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 sentences, front-loaded with what the tool returns and how it is sorted, followed by filter options. Every clause carries information; nothing is redundant 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 read-only, closed-world list tool with full schema coverage and annotations covering safety, the description supplies enough: what a row contains, sort order, and all filter axes. Without an output schema, more detail on row fields/types or truncation behavior would help, but nothing required 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 description coverage is 100%, so every parameter including limit and the enum-like values for kind and category is already documented. The description restates the filter set (since as ISO date, plus kind/category/provider) without adding new semantic detail such as format nuances or default behavior beyond what the schema says. 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 opening clause names the specific resource (dated price changes, new SKUs, delistings, spec changes) and the ordering (newest first), which is clearly distinguishable from siblings like get_history or get_price that operate on a single SKU. It does not explicitly name a sibling or state what it is not, keeping it 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 description gives filter mechanics ('Filter by since, kind, category and provider'), which implies the intended discovery workflow, but never states when to choose this over get_history or search_skus. 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/closed-world, so the safety profile is covered. The description adds genuinely new behavioral facts: results are restricted to active SKUs, data comes from a daily archive rather than live fetching, and each row carries verified_at, a stale flag and source_url — which tells the agent how fresh and trustworthy results are.

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 short sentences, front-loaded with what is searchable and in what dimensions, then constraints, then return shape, then provenance. No filler and nothing redundant with the schema.

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 output schema, the description compensates by enumerating the key return fields (current list price, unit, currency, verified_at, stale, source_url). Minor gaps remain: pagination/limit behavior and the default ordering are only discoverable from the schema, not the description.

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 baseline is 3, but the description adds value the schema lacks: it spells out the category values (vps|gpu|llm) even though the schema declares category as an untyped string with no enum, and clarifies that query is a substring match on name or id.

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 (Find) and resource (VPS plans, GPU instances, LLM models) plus the three filter axes, so an agent knows exactly what is searchable. It does not name a sibling to differentiate from (e.g. get_price vs cheapest_for_spec), so it stops 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?

"Active SKUs only" and "reads the ledger's own daily archive, nothing is fetched live" give real usage context, and the implicit browse-all case is covered by the query parameter. However, there is no explicit when-to-use-this-instead-of guidance relative to get_price, list_changes or cheapest_for_spec.

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