FastGPU

List cheapest GPU prices

list_gpu_prices

Read-onlyIdempotent

One entry per GPU model with its cheapest live on-demand cloud rental price in USD per GPU-hour, the provider offering it, and how many providers rent it, from FastGPU's live price feed across marketplaces, neoclouds and hyperscalers (RunPod, Vast.ai, Lambda, AWS and more). Use it to compare GPU rental prices or to find where a named GPU is cheapest to rent. Each price is the provider's own per-GPU rate: cheapest_min_gpu_count says when it is only sold as a multi-GPU instance, and cheapest_billed_separately names what the provider bills on top of it (CPU, memory, storage), null when the rate includes CPU and memory. page_url links to the GPU's live price page with every offer. Rental prices only: it does not rent, reserve or launch GPUs. No key required.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`tier`	No	Filter by tier.
`vendor`	No	Filter by GPU vendor.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`gpus`	Yes
`count`	Yes
`stale`	No
`updated_at`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 30, 2026

addedOutput schema / properties / gpus / items / properties / page_url

Added value: +{
+  "description": "Absolute URL of this GPU's live price page, with every live offer.",
+  "type": "string"
+}

addedOutput schema / properties / gpus / items / properties / slug
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / gpus / items / properties / url / description

Added value: +"Site-relative path of this GPU's live price page, e.g. /gpus/h100-sxm."

Changed1 schema field changedSep 29, 2026
- addedOutput schema / properties / gpus / items / properties / cheapest_billed_separately
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
Changed1 schema field changedSep 27, 2026
- addedOutput schema / properties / gpus / items / properties / cheapest_min_gpu_count
```
Added value: +{
+  "type": [
+    "integer",
+    "null"
+  ]
+}
```
First observedSep 1, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond them: the data is a live feed, prices are per-GPU-hour in USD, it clarifies that cheapest_min_gpu_count signals multi-GPU-only sales and cheapest_billed_separately names extra billed resources. It also states no key is required and reinforces the read-only scope.

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

Conciseness4/5

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

The core definition is front-loaded in the first sentence, followed by usage, then field-level clarifications. It is dense but every clause carries information; only the parenthetical provider list feels slightly padded.

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

Completeness5/5

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 re-explain return structure, and it still goes further by interpreting the key field names and stating the rental-only limitation. 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.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with both parameters enum-constrained, so the schema already carries the filter semantics. The description offers no additional meaning for 'tier' or 'vendor' beyond restating that they are filters, so this is the baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('one entry per GPU model with its cheapest live on-demand cloud rental price') plus the exact scope (marketplaces, neoclouds, hyperscalers). An agent immediately knows this is a price-listing tool, not a rental or matching tool, which distinguishes it from match_workload.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit use cases ('compare GPU rental prices or find where a named GPU is cheapest to rent') and a clear exclusion ('it does not rent, reserve or launch GPUs'). It does not name match_workload as the alternative for workload-suitability queries, so the routing guidance stops one step 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.

All FastGPU tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?