Skip to main content
Glama

GridHop GPU Price & Carbon Index

Find GPU rental offers

find_offers
Read-onlyIdempotent

Cheapest GPU machines for rent right now across Vast.ai, RunPod, AWS spot and Google Cloud spot, ranked by price. Returns price per hour, provider, country, tier (datacenter or community host), reliability score, whether the price is interruptible (spot), and grid carbon intensity where an open data feed covers the host's grid (Europe and GB live; US by state or cloud region, a day old). Can filter and sort by carbon.Data is refreshed hourly; observed_at is the snapshot time. Read-only, free, no account.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "gpu_class": "<gpu_class>"
    },
    "name": "find_offers"
  }
}

Input Schema

NameRequiredDescriptionDefault
tierNodatacenter keeps only hosts the provider lists as datacenters and drops community hosts (independent hosts on a marketplace)any
countNoGPUs on one machine
limitNoMaximum offers returned, in sort_by order. total_matching gives the full count.
sort_byNoprice: cheapest first. carbon: lowest grid carbon intensity first, cheapest within the same grid; offers with no carbon value go last.price
vram_minNoMinimum VRAM per GPU, GB
gpu_classYesGPU model, e.g. RTX4090, RTX5090, H100, H200, A100_80, A100_40, L40S, A6000, RTX3090, L4, T4. Loose forms like '4090' or 'RTX 4090' work.
providersNoOnly these providers. Default: all.
max_price_hrNoUpper bound on USD per hour for the whole machine
region_filterNoOnly hosts in these ISO 3166-1 alpha-2 countries, e.g. ['US','DE']. Hosts with unknown country are excluded.
min_reliabilityNoDrop hosts whose provider reliability score (0..1, Vast.ai only) is below this. Offers with no score are kept. 0 shows every host.
max_carbon_g_kwhNoOnly hosts on a grid at or below this carbon intensity, gCO2eq/kWh. Offers with no carbon value are dropped when this is set.
include_interruptibleNoOmit (default) to get on-demand prices plus AWS and Google Cloud spot, which are real prices for a running machine. true also adds Vast.ai / RunPod minimum bids, which are a floor rather than the price of keeping the machine. false drops everything interruptible, cloud spot included (every AWS and Google Cloud offer here is spot).

Output Schema

NameRequiredDescriptionDefault
noteNo
offersYes
sourcesNoData sources and attribution
warningsYes
observed_atYesUTC time of the price snapshot (ISO 8601)
total_matchingYesOffers matching the filters before `limit`

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive and openWorld, so safety is covered. The description adds material context beyond that: hourly refresh cadence with `observed_at` as snapshot time, and explicit data-coverage caveats (carbon live for Europe/GB, US by state or cloud region a day old), plus that interruptible offers are bids rather than running-machine prices.

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-loaded with purpose and ranking, then enumeration of return fields, then caveats. The long parenthetical about carbon feed coverage is dense but earns its place; no filler sentences, though a single dense paragraph carrying four distinct ideas.

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?

For a 12-parameter tool with an output schema and full annotations, the description supplies everything else an agent needs: data freshness, cost model, free/no-auth access, provider set, and known data-coverage limitations.

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%, so baseline is 3 and the schema already documents every parameter thoroughly. The description's carbon coverage caveat gives useful context for `max_carbon_g_kwh` and `sort_by=carbon`, but it adds only marginal meaning beyond the already-detailed parameter descriptions.

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 ('Cheapest GPU machines for rent right now'), names the four providers, and specifies the ranking ('ranked by price'). An agent knows exactly what this returns without inspecting the 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 clear operational context — 'Read-only, free, no account' — and implies the filtering use case via 'Can filter and sort by carbon.' It does not state explicit when-not-to-use conditions, but with no sibling tools present there is no alternative to route away from.

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.