Skip to main content
Glama

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

NameRequiredDescriptionDefault
tierNoReturn only one class of GPU (case-insensitive; combines with vendor). flagship: the current top training and inference accelerators (H100, H200, B200, GB200, MI300X, MI355X). datacenter: earlier or mid-range data-center and workstation cards (A100, L40S, L4, A10, RTX 6000 Ada, V100, MI210). prosumer: desktop consumer and workstation cards (RTX 5090, RTX 4090, RTX 3090, RTX A4000). entry: small inference cards (T4, A2, A16, P4). Omit for every tier.
vendorNoReturn only GPUs made by this vendor (case-insensitive). Combines with tier: both must match. Omit for every vendor.

Output Schema

NameRequiredDescriptionDefault
gpusYes
countYes
staleNo
updated_atNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / tier / description
      Previous value: -"Filter by tier."New value: +"Return only one class of GPU (case-insensitive; combines with vendor). flagship: the current top training and inference accelerators (H100, H200, B200, GB200, MI300X, MI355X). datacenter: earlier or mid-range data-center and workstation cards (A100, L40S, L4, A10, RTX 6000 Ada, V100, MI210). prosumer: desktop consumer and workstation cards (RTX 5090, RTX 4090, RTX 3090, RTX A4000). entry: small inference cards (T4, A2, A16, P4). Omit for every tier."
    • changedInput schema / properties / vendor / description
      Previous value: -"Filter by GPU vendor."New value: +"Return only GPUs made by this vendor (case-insensitive). Combines with tier: both must match. Omit for every vendor."
  2. Changed3 schema fields changed
    • 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."
  3. Changed1 schema field changed
    • addedOutput schema / properties / gpus / items / properties / cheapest_billed_separately
      Added value: +{
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
  4. Changed1 schema field changed
    • addedOutput schema / properties / gpus / items / properties / cheapest_min_gpu_count
      Added value: +{
      +  "type": [
      +    "integer",
      +    "null"
      +  ]
      +}
  5. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: 'live' feed, no key required, and the rental-only boundary. Much of the remaining text describes per-entry output fields, which overlaps the output schema.

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?

Front-loads the core purpose and scoping in the first sentence and remains informative throughout. The middle sentences detailing cheapest_min_gpu_count, cheapest_billed_separately and page_url are somewhat redundant against the output schema, costing a little tightness.

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

Completeness4/5

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

Given a moderate-complexity read tool with a full output schema and complete annotations, the description covers source, semantics, and boundaries adequately. Since an output schema exists, its return-field narration is not strictly necessary, leaving a small amount of unearned bulk.

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 description coverage is 100% and both params (tier, vendor) have full enum docs in the schema, so the baseline is 3. The description never mentions tier or vendor filtering, adding no parameter meaning beyond what the schema already provides.

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 in USD per GPU-hour') and names the providers and source feed. It is clearly distinct from the sibling match_workload without needing to open either schema.

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 when-to-use ('compare GPU rental prices or to find where a named GPU is cheapest to rent') plus a firm when-not boundary ('Rental prices only: it does not rent, reserve or launch GPUs'). It does not name the sibling match_workload as the alternative, so it stops short of full routing guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources