Skip to main content
Glama

GPU Economy - cloud GPU prices

Recent price changes

recent_price_changes
Read-only

Listed prices that changed in the last 30 days, one row per quote, newest change first: the figure before its first change in the window, the figure now, and how many times it changed. A quote back at its starting figure is left out, and so are marketplace floors unless asked for. Optionally for one GPU or one provider.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
gpuNoOptional GPU id or name.
limitNoRows; default 20.
providerNoOptional provider id or name.
include_marketplacesNoAlso list marketplace floors (Vast.ai), which move with every read; default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already establish this as a safe read (readOnlyHint=true, openWorldHint=false), yet the description adds real behavior: exclusion of quotes that returned to their starting figure, exclusion of marketplace floors by default, ordering newest-first, and one row per quote. That is meaningful context beyond the safety profile.

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?

Two dense sentences, front-loaded with the core purpose and the row semantics before the optional filtering clause. Slightly run-on, but no filler and every clause carries information.

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 no output schema, the description usefully describes the return shape (prior figure, current figure, change count, ordering) and the exclusion rules. Minor gaps remain around pagination/limit behavior, but nothing critical to invoking the tool correctly is missing.

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 four parameters are already documented, making 3 the baseline. The description reinforces that gpu/provider are optional single-value filters and that marketplaces are excluded 'unless asked for', but adds no format or syntax detail beyond 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?

States a specific verb+resource with the exact scope: 'listed prices that changed in the last 30 days' and the shape of each row. It implicitly differs from sibling tools like gpu_prices/provider_prices (point-in-time prices vs. changes), but never names or contrasts them, so it falls short of a 5.

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

Usage Guidelines3/5

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

Usage is only implied: 'Optionally for one GPU or one provider' hints at filtering but gives no when-to-use guidance, no mention of when to reach for gpu_prices or price_index instead, and no stated prerequisites.

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