GPU Economy - cloud GPU prices

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower, and the description adds real behavioral context: median of 3+ sellers, cheapest vs median rate, the 100/70/50/25% of a 730-hour month scenarios, and explicit exclusions. It does not disclose pagination or result-size behavior when scanning all cards.

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?

Information-dense and roughly three sentences, but it opens with a noun-phrase fragment ('A card's new retail price ... against its live on-demand rental rates:') rather than a front-loaded statement of purpose, and the parentheticals make it slower to parse than 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?

An output schema exists, so return values needn't be explained, yet the description still spells out the methodology (rate basis, utilization levels, exclusions), which is what an agent needs to interpret the numbers. Nothing critical for correct invocation appears 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 the single optional gpu parameter, and the description's 'Without gpu, every card that has a retail median' essentially restates the schema's 'omit for every card with a retail median.' No additional syntax or format meaning is contributed, 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 precise computation: months of rental (at cheapest and median rate) that equal a card's retail price, at four utilization levels. That is a specific verb+resource and distinguishes it in substance from siblings like gpu_prices or estimate_cost, though it never names an alternative 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?

Usage is implied rather than stated: it is clearly a buy-vs-rent break-even analysis, and the 'Rental fee only - power, hosting, the server around the card and resale are not counted' line implies when NOT to rely on it for total cost of ownership. There is no explicit when-to-use guidance or named alternative (e.g., estimate_cost).

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 this is a read-only, non-open-world lookup. The description adds real behavioral value beyond that: it discloses that results are anchored to the provider's own on-demand rate, reports medians, and warns that 'a commitment is paid whether the GPU runs or not' – a caveat the agent should convey when discussing savings. Sorting is disclosed, though only via schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single dense sentence built around an em-dash, and the key idea ('committed and spot rates set against the same provider's own on-demand rate') is front-loaded. However, the mid-sentence detour into 'the pairs behind the site's typical discount with the median per term across every card' burdens a tool description with site-marketing context rather than invocation guidance.

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-value details need not be restated, and all parameters are schema-documented, so the description only needs to convey purpose and caveats – which it largely does, including the commitment-payment warning. The main gap is routing guidance among the many pricing siblings (buy_vs_rent, estimate_cost, gpu_prices), which remains 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 description coverage is 100%, so all three parameters (including the term enum) are already documented at the field level. The description's contribution is limited to restating that omitting gpu means 'every card' and that pairs are compared within the same card/region/scope – consistent with, but not additive to, 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?

The description states a specific computation: committed/spot rates set against the same provider's on-demand rate for the same card, region and price scope, plus medians per term. That is concrete enough to know what the tool returns. It does not, however, distinguish itself from plausibly overlapping siblings such as buy_vs_rent or estimate_cost, which would require reading their 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?

There is no explicit when-to-use statement, no conditions under which this beats buy_vs_rent or estimate_cost, and no prerequisites. Usage is only inferable from the phrase 'the pairs behind the site's typical discount'. The agent is left to guess which sibling fits a savings comparison question.

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 and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: results come from live quotes only (no historical or retail-only fallback), and it names the exact comparison facets returned. It stops short of stating how missing data is handled (e.g. 'retail median where one exists' hints but doesn't explain).

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?

A single front-loaded sentence that opens with the core action and then lists the compared fields; no filler or repetition. The list is long but each field earns its place by telling the agent what data it gets back.

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 explain return values, yet enumerating the compared fields helps an agent decide relevance. Combined with annotations covering the safety profile and full schema coverage, almost nothing needed for correct 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 both parameters are documented there, including the id-or-name format example ('h100-sxm', "H200"). The description adds nothing about parameter interpretation beyond confirming that both inputs are GPU models, 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?

Names a specific verb (compare) and resource (two GPU models) and enumerates exactly which attributes are put side by side (VRAM, median rate card, cheapest on-demand rate, price per GB of VRAM, retail median, provider deltas). This lets an agent distinguish it from gpu_prices (single-model pricing) and compare_providers (provider-level, not GPU-level) 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?

'Live quotes only' scopes the tool to current pricing rather than history, which is a useful selection hint against price_history. However, it never states when to prefer this over compare_providers or gpu_prices, nor any prerequisites, 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 carry readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds meaningful context beyond annotations: the comparison is restricted to on-demand live quotes and deliberately omits community capacity and marketplace floors, which shapes what results mean.

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 what the comparison produces, then scope exclusions and the live-quote constraint. Dense but every clause carries information; the enumerated return fields are slightly run-on.

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 nonetheless frames them. Combined with the scope exclusions and short schemas, an agent has enough to invoke it correctly, with only sibling routing 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 both a and b are already documented including examples (runpod, lambda, "Google Cloud"). The description adds no parameter-level detail, 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 (compare) and resource (two providers) and enumerates what the result contains: each side's cheapest on-demand rate card, the difference, which is lower, and the count. It is clearly distinguishable in spirit from compare_gpus, though it never names that sibling to sharpen the boundary.

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 clear scope context: on-demand only, live quotes only, and explicitly excludes community capacity and marketplace floors. That tells the agent when this tool applies and when to look elsewhere, though it names no alternative tool by name.

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 readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds real value on top by disclosing what is excluded from the estimate (storage, network egress, taxes, idle time) and that prices are listed rates rather than live availability. Those caveats are exactly the kind of assumption an agent needs before presenting a number as a cost.

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 the output shape and followed by the caveat; nothing is padded. It is dense but each clause carries distinct information, so only the slightly clipped phrasing keeps it from a 5.

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 explain return values, and it covers the material assumptions (what is and isn't counted, listed vs available rates). The only gap is that it says nothing about how the 'median rate card' comparison is selected, but the parameter defaults in the schema largely fill that in.

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 fully documents gpu, gpus, hours, limit, market, and region, making 3 the baseline. The description's mention of 'N GPUs', 'a number of hours', and 'the cheapest rate cards' loosely echoes the gpus/hours/limit parameters but adds no syntax or default detail beyond them, and market is not addressed.

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 computation: cost of N GPUs of one model for a number of hours, at the cheapest rate cards and the median, with the arithmetic shown. This is clearly a derived-cost tool rather than a raw price lookup, which separates it from gpu_prices. It does not name any sibling explicitly, 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 description defines the tool's scope ('rental fee only', 'listed rates, not availability') but never says when to reach for it instead of gpu_prices, buy_vs_rent, or token_cost. The scope limits are useful but they are boundary definitions, not use-vs-alternative 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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description usefully adds what the call returns: live rates with read times, as plain text, plus the page URL to cite. It stops short of mentioning rate limits or pagination, but adds genuine return-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?

One dense sentence, front-loaded with the resource, and every clause earns its place by clarifying id source and return shape. The parenthetical id examples make it slightly heavy but are not 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 single-param read tool with an output schema present, the description covers purpose, id provenance, and output form, so the agent has what it needs. Return-value detail is rightly left to the output schema.

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 param is documented as 'An id from search'. The description goes further by illustrating the id namespace with concrete examples (gpu:h100-sxm, provider:runpod, index:h100, reserved, buy-vs-rent), which adds real meaning about valid id forms 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 verb+resource: reads the text of one GPU Economy page identified by an id. It also anchors where that id comes from ('an id from search'), which distinguishes it from the search sibling that produces ids. Not a full 5 because it doesn't explicitly name a competing sibling.

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?

Implies the prerequisite workflow by saying the id comes from 'search', which tells the agent this is a follow-up call. However, there is no explicit when-to-use/when-not or named alternative among the 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 only cover readOnlyHint and openWorldHint, so the description carries the behavioral load and does disclose the sort order (cheapest first), the per-card payload (cheapest live on-demand rate card with provider/read time/page, median rate card and panel size, VRAM, price per GB), and the market-exclusion rule. It stops short of noting caching staleness or pagination 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?

Front-loaded with the qualifying criteria and sort order before the field enumeration, and every clause maps to real output content. It is dense and reads as one long sentence, but there is little outright waste.

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 shape need not be restated, and the description still sketches the key return fields. For a zero-required-parameter filtered query tool this is close to complete, with only sibling routing left 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 coverage is 100%, so baseline is 3, but the description adds real meaning beyond it: it clarifies which market defines the 'cheapest' rate (live on-demand) and that community/marketplace floors stay out unless the market parameter overrides the default. That directly explains the effect of the market parameter on results.

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 (GPU models) qualified by criteria (memory and price requirement) and sort order (cheapest first). The 'meet a requirement' framing distinguishes it from a plain list_gpus, but it never names a sibling to sharpen that contrast.

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 one conditional rule — community capacity and marketplace floors are excluded unless the market is set — which implicitly tells the agent when the default result set is narrowed. However, it offers no guidance on when to use this versus list_gpus, compare_gpus, or gpu_prices.

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 and openWorldHint=false, so safety is covered. The description goes further by disclosing the sort order (cheapest first), freshness ('Live quotes only'), and what each row carries (read time plus a source link), which is useful behavioral context beyond the 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?

Two sentences, front-loaded with the resource and scope, no filler. Every clause (across providers, cheapest first, per GPU-hour, live only) 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 further explanation, and the description covers scope, ordering, currency, and freshness. Only the when-to-use routing against sibling pricing tools is 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 all four parameters (gpu, limit, market, region) are already documented in the schema with defaults and enums. The description reinforces 'cheapest first' and 'USD per GPU-hour' but adds no syntax or format detail the schema lacks; 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 listed rental prices for one GPU model) with scope details: across providers, cheapest first, USD per GPU-hour. This is specific enough that an agent can distinguish it from price_history (historical) and price_index 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?

'Live quotes only' implicitly excludes the history sibling, but the description never explicitly says when to use this versus provider_prices, compare_providers, or price_index. Usage context 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 and openWorldHint=false, so the safety profile is covered. The description adds payload-level context (provider counts, median on-demand rate in USD per GPU-hour), but much of that restates return fields rather than disclosing behavior like ordering or completeness guarantees.

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?

A single front-loaded sentence with no filler; every clause describes a returned attribute of value. Nothing to trim.

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 needn't enumerate return values, and its brief preview of fields is a useful orientation. For a no-argument read-only list tool this is essentially complete, lacking only notes on ordering or scope limits.

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 per the rubric the baseline is 4. There is no argument surface the description needs to explain.

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 ('list GPU models') plus the exact fields returned, so the agent knows this is a full-catalog enumeration. It doesn't explicitly contrast itself with close siblings like find_gpus or compare_gpus, but the 'every GPU model tracked' framing implies completeness versus a filtered search.

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: enumerating the whole tracked catalog. There is no explicit when-to-use statement, no when-not-to-use, and no named alternative among siblings such as find_gpus (search) or gpu_prices (rates).

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 (readOnlyHint=true, openWorldHint=false), and the description adds real context beyond them: results are newest-week-first, the two sources are kept separate rather than blended, one series is a reconstructed second-hand catalog, and each week carries a panel size. It does not discuss rate limits or caching, but the provenance disclosure is genuinely useful.

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 sentences, front-loaded with what the tool returns and from which sources. The closing clause 'read a median against it' is terse to the point of being cryptic, 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?

A read-only query tool with a full output schema, so return-shape explanation is not required, yet the description usefully explains that medians/cheapest values are per-week and per-source with a panel size. Nothing essential for correct invocation is missing; only the alternative-tool 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 description coverage is 100%, so both params (gpu, weeks) are already documented, including the default of 12 and the newest-first ordering. The description repeats the newest-first framing but adds no syntax or format detail beyond the schema, so baseline 3 applies. The 'read a median against it' note guides interpretation rather than parameter meaning.

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: weekly median and cheapest listed on-demand rate for one GPU model. It also names the two distinct sources (own hourly reads vs. a reconstructed public-catalog second-hand series), which sharply separates it from siblings like gpu_prices, price_index, and recent_price_changes.

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 (this is the tool for weekly historical rates for a single GPU), but the description never says when to prefer it over siblings such as recent_price_changes or price_index, nor any exclusions. The agent must infer routing from the phrasing 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 declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful shape detail (fixed panel, base-100 index, receipts, monthly averages), but says nothing about provider coverage limits, how the fixed panel is composed, or freshness beyond 'newest hourly point'.

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?

A single compact sentence that front-loads the resource and headline metric. It is somewhat jargon-dense ('receipts', 'base-100 index') but wastes no sentences and nothing is buried.

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-value detail is not the description's burden, and the one optional enum param is fully documented in schema. For a zero-required-parameter read tool the description is nearly complete, only missing 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% and the enum values week/hour/month are documented in the schema, including the 'which window leads the answer' behavior. The description adds nothing parameter-specific, 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 and scope: median listed on-demand H100 SXM rate across providers, this week plus eight prior weeks, with the base-100 index and monthly averages. This clearly separates it from gpu_prices and price_history, though it reads more as a content inventory than an action statement.

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 when-to-use or when-not-to-use guidance. The description never mentions gpu_prices, price_history, or provider_prices, so the agent must infer that this is the H100-specific index view rather than a general price lookup. The 'window' default is the only steering signal, and that lives in the schema.

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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds modestly useful context by disclosing data provenance ('how GPU Economy reads its prices (pricing page, API or rendered page)') and the 'where read' qualifier implying fields may be absent, but says nothing about unknown-provider handling or freshness.

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 but front-loaded sentence that enumerates the returned content with no filler; the profile contents come first and the trailing externally-hosted page link is the only extra. It is long but every clause maps to a field an agent would care about.

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 one-parameter read tool with an output schema and read-only annotations, this is largely complete — and it even pre-describes return fields the output schema already covers. Only the routing against sibling provider tools 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 the single `provider` parameter is already documented with format examples in the schema. The description adds no syntax or matching guidance beyond what the schema provides, 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 plus title make clear this returns a profile of a single provider — its type, coverage, pricing-read method, model/quote counts, cheapest rate and extra billing items. It is a specific resource with a clear scope, but it never distinguishes itself from siblings like compare_providers or provider_prices, so an agent must infer the boundary.

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 statement, and no alternatives are named. The agent is left to infer that this is the single-provider detail lookup and that compare_providers/provider_prices cover the multi-provider and price-only cases.

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 and openWorldHint=false, so the safety profile is covered. The description adds real behavioral detail beyond that: the currency/unit (USD per GPU-hour), that each record carries a read time and a source-linking GPU Economy page, and that only live quotes are returned.

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 front-loaded sentence plus a short qualifier; the key scope ('at one provider') and unit arrive first. The parenthetical provider list is slightly redundant with the schema but stays compact.

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 the description need not detail return values, and it still summarizes what each record contains (price, read time, source page). Combined with the 100% covered single parameter and clear read-only annotations, nothing needed to invoke the tool 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 the single provider parameter is already fully documented in the schema, including the id/name distinction and examples. The description echoes the same provider examples without adding new syntax or formatting guidance, 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+resource (current listed rental prices) and a clear scope constraint ('at one provider'), and the USD per GPU-hour unit anchors what a price means. It implicitly distinguishes itself from price_history and recent_price_changes via 'current' and 'Live quotes only', though it never names those siblings outright.

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 agent can infer this is the tool for enumerating all listed quotes for a single provider. There is no explicit when-to-use guidance against compare_providers, gpu_prices, or price_history, and no stated exclusions beyond 'Live quotes only'.

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 mark this read-only and closed-world, and the description adds substantive behavior on top: the 30-day window, newest-change-first ordering, omission of quotes that returned to their starting figure, and the fact that marketplace floors move on every read (which is why they're opt-in). That volatility note is exactly the kind of context annotations cannot 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?

One dense, front-loaded sentence leads with the resource and window, then the row shape, then exclusions. Tight with no filler, though the packed clause chain makes it slightly heavy to parse.

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-value explanation is unnecessary, and the description still covers scope, ordering, and exclusions. Combined with the read-only annotation and full schema coverage, 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 coverage is 100% and every parameter is self-documented, so the schema already carries the load. The description reinforces the opt-in nature of marketplace floors and the filtering role of gpu/provider, but adds no new syntax, format, or default 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?

Names a specific resource (listed prices that changed in the last 30 days) with the exact row granularity, ordering, and contents of each row. Exclusions and scope limits are stated, so an agent can distinguish it from price_history or price_index without reading 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?

It says results can optionally be narrowed 'for one GPU or one provider,' implying how the params are used, and states two exclusion conditions. But it never says when to pick this over price_history/price_index, nor names an alternative for full history or un-changed prices.

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 and openWorldHint=false, so the safe-read profile is covered. The description adds the result shape (ids for fetch, title, URL), but says nothing about ranking, result limits, or empty-result behavior. Given annotations carry the safety burden, a 3 is appropriate.

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 sentence, front-loaded with the core action, then the return contract. No filler and no redundancy.

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 one-parameter read tool with annotations and an output schema, the description covers what it does and what it returns, and links to the fetch follow-up. Only the lack of differentiation from closely related siblings keeps it from a 5.

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?

There is a single parameter with 100% schema description coverage, so the schema already supplies the query semantics and examples. The description's restatement of example queries adds little beyond the schema, making the standard baseline of 3 correct.

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 (GPU Economy pages), and enumerates the kinds of things a query can target (GPU, provider, price index, reserved rates, buy vs rent). It also clarifies the return contract (ids for fetch plus title and URL). It stops short of distinguishing itself from siblings like find_gpus, gpu_prices, or price_index.

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 query examples and by the mention that the returned ids feed 'fetch', which is a sibling. However, there is no explicit when-to-use/when-not guidance and no statement about how this differs from the more targeted sibling 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?

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing that the figure is modelled rather than measured, exactly how it is derived, that NVIDIA's run conditions differ per card, and that idle GPU time is a floor rather than a bill. This is unusually rich disclosure of limitations for a read-only cost tool.

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 caveat 'Modelled, not measured' and tightly packed, though the second and third sentences are dense and long. Every clause carries information, but structure leans on em-dash chains rather than separate, scannable 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?

With an output schema present, the description need not explain return values, and it supplies the methodological context an agent needs to avoid misreading a modelled floor as an actual bill. It could still say which sibling to use for measured prices, but coverage of the conceptual model is solid.

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 params (gpu, model) are already documented in the schema, including the supported card list and the default-all-models behaviour. The description adds no parameter syntax or format detail beyond that, 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 quantity: cost per million output tokens, derived from a GPU-hour rate and published throughput. It is clearly a modelled per-token cost, not a raw price, which implicitly separates it from gpu_prices or estimate_cost, but it never names a sibling or frames its purpose in the first clause — the lead is a caveat, not a definition.

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 through caveats: 'cards are not comparable on it' and 'a floor, never a bill' tell the agent how to read the number but not when to call this tool versus estimate_cost or gpu_prices. No explicit when-to-use/when-not or alternative tool is named.

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