Live cloud GPU prices, observed stock and 12-month price history across 30+ providers (H100, H200, A100, RTX 5090 and more), refreshed hourly. Read-only. Needs a GPU Finder API key sent as "Authorization: Bearer "; free key with 60 data calls a month at https://gpufinder.dev/developers. Listing tools and get_usage are free.
Scored across 8 tools
Most tools target a clearly distinct object: list_gpus/list_providers enumerate catalogs, get_prices lists all offers, get_market_snapshot returns cheapest in-stock offers for an exact GPU count, get_availability is day-by-day stock history, get_price_history is monthly price history, and get_data_status/get_usage are metadata. The closest pair, get_prices vs get_market_snapshot, is separable but requires reading carefully since both return current offer prices for a model. Overall boundaries are clear, with only that one adjacency to watch.
Every tool follows a strict snake_case verb_noun pattern using get_ or list_ prefixes (get_availability, get_market_snapshot, list_gpus, list_providers). Nouns map cleanly to the resource or data dimension being returned. No style mixing or vague verbs.
Eight tools is well within the ideal 3-15 range and each earns its place: two catalog lists, three current-data tools, two history tools, and two metadata/account tools. Nothing appears redundant or padded.
The surface covers the full read lifecycle: discovery (list_gpus, list_providers), current pricing (get_prices, get_market_snapshot), history (get_availability, get_price_history), and operational metadata (get_data_status, get_usage). Gaps are minor: there is no direct lookup/detail tool for a single GPU or provider by slug, and no server-side search or filtering by specs such as VRAM or price band, forcing clients to page through lists. Notifications/scheduling are explicitly out of scope, so their absence is not a fault.
Show day-by-day stock for one GPU model over the last seven days, per provider and node size: available configuration-hours versus known configuration-hours each day, summed across tracked instances. Optionally limit to one provider. Reports observed availability history, not provider uptime or launch guarantees. Days without observations are unknown, not zero. Pages default to 20 rows, maximum 100; each page costs one data unit.
| Name | Required | Description | Default |
|---|---|---|---|
| gpu | Yes | GPU model name, case-insensitive, e.g. "H100", "RTX 4090". See list_gpus. | |
| page | No | Pagination. Omit for the first page. | |
| provider | No | Provider name or slug, e.g. "runpod", "lambda". See list_providers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which already cover readOnly/non-destructive), the description discloses the exact metric being summed, the crucial semantic caveat that missing days are unknown rather than zero, and the cost model of one data unit per page. Those are behavioral facts an agent could not derive from the structured fields and that materially affect result interpretation and call budgeting.
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 core behavior, then caveats, then cost/pagination. Every sentence carries distinct information; the metric definition, the 'not zero' warning, and the data-unit cost are all non-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?
There is no output schema, so the description must explain what comes back, and it does precisely (per-day, per-provider, per-node-size available vs known configuration-hours). Combined with annotations and a fully documented schema, an agent has everything needed to call this correctly and interpret the response.
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 gpu, provider, and the pagination object are already fully documented. The description only restates that provider is an optional narrowing filter and repeats the page defaults, adding no new syntax or constraint information. Baseline 3 applies when the schema does the heavy lifting.
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 (day-by-day stock) with explicit scope: one GPU model, last seven days, per provider and node size, measured as available vs known configuration-hours. That metric definition is distinctive enough to separate it from get_price_history and get_market_snapshot without opening 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?
Scope is clear enough to imply when the tool applies (historical availability, not pricing or uptime), and the 'observed availability, not uptime or launch guarantees' line sets a boundary on interpretation. However, it never explicitly names a sibling or says when to prefer this over get_market_snapshot or get_prices, so routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report how fresh GPU Finder's data is: when price and availability collection last completed, and each provider's last success, last run, consecutive failures and last error. Includes timestamps for assessing data staleness. Costs one data unit; it is not an anonymous health check.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, non-destructive, closed-world behavior, but the description adds meaningful context: it costs one data unit, is not an anonymous health check, and lists provider failure/error fields returned. It does not detail rate limits or authentication mechanics, but it adds useful behavioral information beyond 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 purpose is front-loaded in the first sentence, followed by the returned fields and an important cost warning. The description is compact and every sentence contributes useful context.
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 parameterless read-only status tool with no output schema, the description adequately summarizes return values and includes the important data-unit cost. It does not describe the exact response shape, but it provides enough information for an agent to call and interpret it.
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 has zero parameters, so there are no parameter semantics to clarify. The baseline for a parameterless tool is 4.
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: reporting GPU Finder data freshness, with enumerated fields such as price/availability collection completion and provider success/failure history. It is clearly distinct from price and availability retrieval siblings, though it does not explicitly name or contrast them.
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 through 'assessing data staleness' and the cost warning, but there is no explicit guidance on when to use this versus get_prices, get_availability, or other sibling tools. It also does not state when not to use it beyond not being an anonymous health check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a GPU configuration once or in a client-scheduled availability watch: cheapest listed and freshly observed in-stock offers for one GPU model and exact GPU count, with whole-node/per-GPU hourly USD price, observation time, provider and region. Optional provider and exact provider-reported region filters run before regional aggregation and are echoed in filters. Compare snapshots in client-owned state; ignore timestamp-only changes. The server does not schedule checks or send notifications. One data unit per call; get_usage is free. Stock is not a launch guarantee.
| Name | Required | Description | Default |
|---|---|---|---|
| gpu | Yes | GPU model name, case-insensitive, e.g. "H100", "RTX 4090". See list_gpus. | |
| count | No | GPUs per node. Prices are for the whole node. Defaults to 1. | |
| region | No | Exact provider-reported region, case-insensitive (e.g. Japan or eu-north1). Obtain labels from get_prices. Not a broad Europe/Asia filter or a placement guarantee. | |
| provider | No | Provider name or slug, e.g. "runpod", "lambda". See list_providers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent annotations: discloses billing semantics ('One data unit per call; get_usage is free'), that the server does not schedule checks or send notifications, that filters run before regional aggregation and are echoed in filters, and that stock is not a launch guarantee. These are exactly the behavioral facts an agent needs before invoking.
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 core return content, then layers constraints and caveats in short clauses. Dense but virtually every sentence carries operational meaning; only the billing aside ('get_usage is free') is slightly tangential to selection.
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?
No output schema exists, so the description must describe return content, and it does: per-GPU and whole-node hourly USD price, observation time, provider, region, and echoed filters. It also covers side effects, billing units, and stock caveats, leaving no obvious 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 coverage is 100%, so the baseline is 3; the description earns an upgrade by clarifying that count is 'exact GPU count' with whole-node pricing and that provider/region filters are applied before regional aggregation and echoed back. It doesn't re-explain formats (case-insensitivity, label sources) that the schema already covers, which 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 and resource: returns cheapest listed and freshly observed in-stock offers for one GPU model and exact GPU count, along with price, timestamp, provider and region. An agent can tell it apart from get_prices/get_availability in broad terms, though the description never explicitly names which sibling to use for related needs (e.g., historical or broad price listing).
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?
Clearly frames the usage pattern: 'Check a GPU configuration once or in a client-scheduled availability watch,' and explains client-owned comparison state, ignoring timestamp-only changes, and that the server does not schedule or notify. Missing explicit when-not or alternative-tool routing against get_availability and get_prices, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show how one GPU model's price changed month by month per provider: on-demand and spot USD per whole node hour for up to 12 UTC months. Pages default to 20 rows, maximum 100; each page costs one data unit. Reuse the same filters and page limit with nextCursor.
| Name | Required | Description | Default |
|---|---|---|---|
| gpu | Yes | GPU model name, case-insensitive, e.g. "H100", "RTX 4090". See list_gpus. | |
| page | No | Pagination. Omit for the first page. | |
| count | No | GPUs per node. Prices are for the whole node. Defaults to 1. | |
| months | No | UTC months of history per provider, 1-12. Defaults to 12. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description goes beyond them with genuinely useful facts: each page costs one data unit, the 20/100 row defaults, and the 12-month UTC cap — quota cost in particular is not derivable from annotations or 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?
Three dense sentences, front-loaded with purpose, then pagination/cost, then cursor continuation; nothing is padding. The final sentence largely repeats the schema's own cursor instruction ('Reuse the same filters and limit'), a minor redundancy that keeps it off 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?
For a 4-parameter, nested-pagination tool with no output schema, the description covers purpose, units, history depth, page sizing and data-unit cost, which is enough to invoke correctly. It omits anything about data freshness/availability (covered by get_data_status) or what a row contains, leaving small gaps.
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, page.limit, page.cursor, count and months are all documented in the schema already, setting a baseline of 3. The description adds only marginal meaning — 'USD per whole node hour' hints at how count scales pricing — while otherwise restating the 20/100 limit and 12-month cap.
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 opens with a specific verb and resource ('Show how one GPU model's price changed month by month per provider') and pins down units ('on-demand and spot USD per whole node hour'). It separates itself implicitly from snapshot-style siblings by emphasising monthly history, but never names get_prices or get_market_snapshot, 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?
Usage is only implied: 'month by month' tells the agent this is the trend/history call and the cursor note explains continuation, but there is no explicit when-to-use versus get_prices, get_market_snapshot or get_availability, and no prerequisites or exclusions. The agent must infer the routing from the noun 'history'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every provider offer for one GPU model and node size: provider, instance type, region, GPU count, on-demand and spot USD price per whole node hour, links and last update. Prices reflect collected data, not a live capacity guarantee. Pages default to 20 rows, maximum 100; each page costs one data unit.
| Name | Required | Description | Default |
|---|---|---|---|
| gpu | Yes | GPU model name, case-insensitive, e.g. "H100", "RTX 4090". See list_gpus. | |
| page | No | Pagination. Omit for the first page. | |
| count | No | GPUs per node. Prices are for the whole node. Defaults to 1. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds genuinely new behavior: the data is collected rather than live, and each page costs one data unit — a quota/cost disclosure an agent would otherwise miss. It does not explain the non-idempotent pagination behavior implied by idempotentHint=false.
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 dense sentences, no filler: returned fields first, then the data-freshness caveat, then pagination and cost. Front-loaded and every sentence carries information an agent 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?
There is no output schema, so the description compensates by enumerating the returned columns. Combined with pagination defaults, per-page cost, and the non-live-data caveat, nothing an agent needs to call this 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 the schema documents gpu, page.limit, page.cursor, and count. The description still adds unit semantics absent from the schema — prices are USD per whole node hour, and node size is controlled via count — which is more than restating field docs.
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 every provider offer for one GPU model and node size') and enumerates the returned fields (provider, instance type, region, GPU count, on-demand/spot price, links, last update). It is distinguishable from get_price_history and get_market_snapshot by its per-model offer scope, though it never names those siblings to make the boundary explicit.
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: 'Prices reflect collected data, not a live capacity guarantee' hints that capacity questions belong to get_availability, but no explicit when-to-use or when-not-to-use rule is given. An agent facing get_price_history, get_market_snapshot, and get_availability must infer which tool answers which question.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show this account's usage across REST and MCP: plan allowance, units used and remaining, and UTC reset times. Spends no monthly units and works after the monthly allowance is exhausted, but is still rate limited.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, non-destructive and non-open-world, and the description adds traits annotations cannot express: no monthly unit spend, availability after allowance exhaustion, and that rate limiting still applies. It also implies the values are time-varying, consistent with idempotentHint=false, and outlines the returned 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, zero filler: the first delivers scope and return contents, the second delivers the cost/quota/rate-limit behavior. The most decision-relevant facts are front-loaded.
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 zero-parameter read with no output schema, the description supplies everything needed: what it returns, that it is free of quota cost, that it survives quota exhaustion, and that rate limits still bind.
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 implies the account is implicit ('this account's') rather than a required argument, leaving no ambiguity an agent would need to resolve.
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 ('Show this account's usage') and enumerates exactly what is returned: plan allowance, units used and remaining, and UTC reset times. That enumeration distinguishes it from the sibling status-style tools (get_availability, get_data_status) without needing to name them.
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 calling context: it costs no monthly units and remains usable after the monthly allowance is exhausted, so an agent knows it is a safe diagnostic call at any time. It stops short of naming an alternative or stating when not to use it, so it is clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the GPU models GPU Finder tracks: canonical name and slug, VRAM, memory type, bandwidth, interconnect, provider and instance counts, and min/max hourly USD price. Returns canonical GPU identifiers and hardware specifications. Pages default to 20 rows, maximum 100; each page costs one data unit.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Pagination. Omit for the first page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely new context beyond annotations: page size defaults and caps, cursor-based paging, and the cost model ("each page costs one data unit") — a rate-limit-style disclosure the agent cannot 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?
Three tight sentences: identity of the resource first, return contents second, operational paging/cost constraints last. No redundancy or filler, and every clause carries information an agent 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?
There is no output schema, so the description must carry the return shape — and it does, naming identifiers, VRAM, memory type, bandwidth, interconnect, provider/instance counts, and min/max hourly USD price. Combined with paging and cost disclosure, an agent has everything needed to call this 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%, including descriptions for limit and cursor, so the schema does the heavy lifting and baseline 3 applies. The description restates the 20/100 pagination bounds and adds that page count drives data-unit cost, but contributes no new meaning about the cursor or filter semantics.
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 the GPU models GPU Finder tracks") and immediately enumerates the fields returned, so the agent knows exactly what comes back. The resource is clearly distinct from sibling tools like list_providers and get_prices, so no confusion is possible.
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 — browse the GPU catalog — but the description never states when to prefer this over get_prices, get_availability, or get_market_snapshot. Pagination guidance is present ("Pages default to 20 rows, maximum 100"), but there are no explicit exclusions or routing rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List GPU cloud providers: name and slug, GPU and instance counts, min/max hourly USD price, egress cost per GB and free egress allowance, website and GPU Finder links, and last update time. Returns canonical provider identifiers and provider-level summaries. Pages default to 20 rows, maximum 100; each page costs one data unit.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Pagination. Omit for the first page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/destructive/openWorld, so the safety profile is covered; the description goes further by disclosing page size defaults (20), the 100-row cap, and that 'each page costs one data unit' — a real cost/quota signal an agent needs before paginating. It stops short of explaining cursor expiry or ordering, which keeps it from 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 sentences: a dense field enumeration followed by pagination/cost rules, with the tool's identity front-loaded. The field list is long but each item is information an agent would otherwise have to infer, so 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?
With no output schema, the description carries the return-value burden and does so by enumerating the returned columns and noting canonical identifiers plus provider-level summaries. Pagination and cost are covered; only ordering and auth/quota context are 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 nested page object already documents limit (1-100, default 20) and cursor (nextCursor reuse). The description restates the default and maximum and adds the data-unit cost per page, but adds no new meaning about cursor semantics or filter reuse 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?
Opens with a specific verb+resource ('List GPU cloud providers') and enumerates exactly which fields come back (name, slug, counts, price range, egress, links, update time), so an agent knows this is the provider-catalog endpoint rather than a GPU- or price-level one. It does not explicitly name the sibling it is not (e.g. list_gpus), 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 never says when to reach for this tool versus get_prices, list_gpus, or get_market_snapshot, nor any prerequisite or exclusion. The only guidance present is mechanical pagination/cost behavior, not usage selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_market_snapshot2 fields changedInput schema / properties / providerAdded value: +{
+ "description": "Provider name or slug, e.g. \"runpod\", \"lambda\". See list_providers.",
+ "maxLength": 100,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / regionAdded value: +{
+ "description": "Exact provider-reported region, case-insensitive (e.g. Japan or eu-north1). Obtain labels from get_prices. Not a broad Europe/Asia filter or a placement guarantee.",
+ "maxLength": 100,
+ "minLength": 1,
+ "type": "string"
+}get_availability5 fields changedInput schema / properties / gpu / descriptionAdded value: +"GPU model name, case-insensitive, e.g. \"H100\", \"RTX 4090\". See list_gpus."Input schema / properties / page / descriptionAdded value: +"Pagination. Omit for the first page."Input schema / properties / page / properties / cursor / descriptionAdded value: +"nextCursor from the previous page. Reuse the same filters and limit."Input schema / properties / page / properties / limit / descriptionAdded value: +"Rows per page, 1-100. Defaults to 20."Input schema / properties / provider / descriptionAdded value: +"Provider name or slug, e.g. \"runpod\", \"lambda\". See list_providers."get_market_snapshot2 fields changedInput schema / properties / count / descriptionAdded value: +"GPUs per node. Prices are for the whole node. Defaults to 1."Input schema / properties / gpu / descriptionAdded value: +"GPU model name, case-insensitive, e.g. \"H100\", \"RTX 4090\". See list_gpus."get_price_history6 fields changedInput schema / properties / count / descriptionAdded value: +"GPUs per node. Prices are for the whole node. Defaults to 1."Input schema / properties / gpu / descriptionAdded value: +"GPU model name, case-insensitive, e.g. \"H100\", \"RTX 4090\". See list_gpus."Input schema / properties / months / descriptionAdded value: +"UTC months of history per provider, 1-12. Defaults to 12."Input schema / properties / page / descriptionAdded value: +"Pagination. Omit for the first page."Input schema / properties / page / properties / cursor / descriptionAdded value: +"nextCursor from the previous page. Reuse the same filters and limit."Input schema / properties / page / properties / limit / descriptionAdded value: +"Rows per page, 1-100. Defaults to 20."get_prices5 fields changedInput schema / properties / count / descriptionAdded value: +"GPUs per node. Prices are for the whole node. Defaults to 1."Input schema / properties / gpu / descriptionAdded value: +"GPU model name, case-insensitive, e.g. \"H100\", \"RTX 4090\". See list_gpus."Input schema / properties / page / descriptionAdded value: +"Pagination. Omit for the first page."Input schema / properties / page / properties / cursor / descriptionAdded value: +"nextCursor from the previous page. Reuse the same filters and limit."Input schema / properties / page / properties / limit / descriptionAdded value: +"Rows per page, 1-100. Defaults to 20."list_gpus3 fields changedInput schema / properties / page / descriptionAdded value: +"Pagination. Omit for the first page."Input schema / properties / page / properties / cursor / descriptionAdded value: +"nextCursor from the previous page. Reuse the same filters and limit."Input schema / properties / page / properties / limit / descriptionAdded value: +"Rows per page, 1-100. Defaults to 20."list_providers3 fields changedInput schema / properties / page / descriptionAdded value: +"Pagination. Omit for the first page."Input schema / properties / page / properties / cursor / descriptionAdded value: +"nextCursor from the previous page. Reuse the same filters and limit."Input schema / properties / page / properties / limit / descriptionAdded value: +"Rows per page, 1-100. Defaults to 20."get_availabilityget_data_statusget_market_snapshotget_price_historyget_pricesget_usagelist_gpuslist_providersLive GPU rental market: 2,500+ offers across a dozen provider feeds. History, watches, limit orders.
Cloud GPU prices with live stock from 22 providers. Find where to rent an H100 or B300 now.
LLM and GPU rental prices: model price lookup, GPU listings, cheapest-GPU search, price history
Published list prices of compute (VPS, GPU hours, LLM tokens, media), archived daily. Read-only.
Add one secure layer between your agents and this server.
