Hundredth Run GPU Cloud Prices

Search GPU rental price rows

get_prices

Read-onlyIdempotent

Search the raw per-provider GPU rental price table (USD per GPU-hour), sorted cheapest first. Use this when you need more than the single cheapest offer: comparing providers for one GPU, finding spot, preemptible or reserved rates, or checking one provider's prices. For just the lowest on-demand price of one GPU, call cheapest_gpu; for an overview of all GPUs, call list_gpus. Returns up to limit rows, each with provider, gpu, variant, price, price_type, term, region, source_url and date_checked. Rows without a public numeric price (contact sales) are excluded.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_prices"
  }
}

Input Schema

Name	Required	Description
`gpu`	No	Exact GPU model to match, case and punctuation insensitive, e.g. H100, H200, A100, L40S, B200, MI300X. Omit for all GPUs.
`limit`	No	Maximum rows to return after sorting cheapest first (1 to 50, default 10).
`provider`	No	Provider name or part of it, case insensitive, e.g. "runpod", "lambda", "vast", "aws". Omit for all providers.
`price_type`	No	Pricing model to keep: on_demand (pay as you go), spot or preemptible (interruptible discount), reserved (committed term), serverless_per_second. Omit for all types.

Output Schema

Name	Required	Description	Default
`rows`	Yes
`count`	Yes	Number of rows returned

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-derivable behavior: results are ordered cheapest-first before truncation, only up to `limit` rows come back, and rows without a public numeric price (contact sales) are excluded — that exclusion rule is the most valuable disclosure here. It stops short of noting pagination or how ties/missing regions are handled.

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

Conciseness5/5

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

Three sentences, each load-bearing: capability and ordering first, routing guidance second, return shape and exclusion rule last. No filler, no restatement of the name, and the key routing information is front-loaded.

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 4-parameter, all-optional filtered search with an output schema present, the description covers what is searched, ordering, truncation, exclusions, and when to prefer siblings. The field list partly duplicates the output schema but is harmless and consistent with it.

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% and the schema already explains gpu matching, provider substring matching, price_type enum values, and that limit applies after cheapest-first sorting. The description's 'up to `limit` rows' and 'sorted cheapest first' restate what the schema says, adding no new parameter meaning. Baseline 3 applies.

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?

The description gives a specific verb and resource — 'Search the raw per-provider GPU rental price table (USD per GPU-hour)' — plus scope and ordering ('sorted cheapest first'). It explicitly contrasts itself with siblings cheapest_gpu (single lowest price) and list_gpus (overview of all GPUs), so an agent can select it 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.

Usage Guidelines5/5

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

It states the positive condition ('when you need more than the single cheapest offer'), enumerates concrete use cases (comparing providers for one GPU, spot/preemptible/reserved rates, one provider's prices), and names both alternatives with the exact condition that selects each.

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

All Hundredth Run GPU Cloud Prices 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.