GPU Economy - cloud GPU prices

What a 1- or 3-year commitment saves

commitment_savings

Read-only

Committed and spot rates for one GPU (or every GPU) set against the same provider's own on-demand rate for the same card, region and price scope - the pairs behind the site's typical discount - with the median per term across every card. A commitment is paid whether the GPU runs or not.

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": "commitment_savings"
  }
}

Input Schema

Name	Required	Description
`gpu`	No	Optional GPU id or name; without it, every card.
`term`	No	Which market to pair; default any (1-year, 3-year and spot).
`limit`	No	Pairs to return, largest saving first; default 15.

Output Schema

Name	Required	Description
`gpu`	No
`note`	No
`page`	No
`term`	No
`pairs`	No
`method`	No
`cite_as`	Yes	How to cite this answer: GPU Economy, the page, the data date.
`attribution`	Yes
`pairs_found`	No
`data_updated_at`	Yes	Newest scrape behind the answer (ISO 8601).
`typical_by_term`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 1, 2026

addedOutput schema / properties / cite_as

Added value: +{
+  "description": "How to cite this answer: GPU Economy, the page, the data date.",
+  "type": "string"
+}

addedOutput schema / properties / page
```
Added value: +{}
```

changedOutput schema / required

Previous value: -[
-  "data_updated_at",
-  "attribution"
-]New value: +[
+  "data_updated_at",
+  "attribution",
+  "cite_as"
+]

AddedOct 1, 2026

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already establish this is a read-only, non-open-world lookup. The description adds real behavioral value beyond that: it discloses that results are anchored to the provider's own on-demand rate, reports medians, and warns that 'a commitment is paid whether the GPU runs or not' – a caveat the agent should convey when discussing savings. Sorting is disclosed, though only via schema.

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

Conciseness3/5

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

It is a single dense sentence built around an em-dash, and the key idea ('committed and spot rates set against the same provider's own on-demand rate') is front-loaded. However, the mid-sentence detour into 'the pairs behind the site's typical discount with the median per term across every card' burdens a tool description with site-marketing context rather than invocation guidance.

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?

With an output schema present, return-value details need not be restated, and all parameters are schema-documented, so the description only needs to convey purpose and caveats – which it largely does, including the commitment-payment warning. The main gap is routing guidance among the many pricing siblings (buy_vs_rent, estimate_cost, gpu_prices), which remains absent.

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%, so all three parameters (including the term enum) are already documented at the field level. The description's contribution is limited to restating that omitting gpu means 'every card' and that pairs are compared within the same card/region/scope – consistent with, but not additive to, the schema.

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

Purpose4/5

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

The description states a specific computation: committed/spot rates set against the same provider's on-demand rate for the same card, region and price scope, plus medians per term. That is concrete enough to know what the tool returns. It does not, however, distinguish itself from plausibly overlapping siblings such as buy_vs_rent or estimate_cost, which would require reading their schemas.

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

Usage Guidelines2/5

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

There is no explicit when-to-use statement, no conditions under which this beats buy_vs_rent or estimate_cost, and no prerequisites. Usage is only inferable from the phrase 'the pairs behind the site's typical discount'. The agent is left to guess which sibling fits a savings comparison question.

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

All GPU Economy - cloud GPU 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.

Resources

Need Help?