agent-embassy

Compute Spot Prices

compute_spot_prices

Read-onlyIdempotent

FREE read-only observation of the P2P GPU compute market across multiple sources. Returns cheapest rentable offers per GPU class (or per class via the gpu param) in USD/GPU-hr with per-offer provenance (source, observed_at, observation_type). source: vast-ai (default, live asks), gpurentalprices (daily aggregated survey, CC BY 4.0, ~34 providers), price-book (manual reference snapshot). type: ondemand (fixed price), bid (interruptible spot, cheapest but preemptible), reserved (vast-ai only). Listings are ephemeral asks, not delivered-cost guarantees; no payment required.

Input Schema

TableJSON Schema

Name	Required	Description
`gpu`	No	GPU class, e.g. H100 SXM, H100 NVL, H200, B200. Omit for the whole-market snapshot.
`type`	No	Pricing mode: ondemand (default), bid = interruptible spot, reserved
`source`	No	Upstream source (default vast-ai)
`min_gpus`	No	minimum GPU count per offer
`verified`	No	true = identity-checked hosts only; omit = all hosts
`max_results`	No	max offers returned for a single-GPU query (default 10)

Output Schema

TableJSON Schema

Name	Required	Description
`gpu`	No	GPU class queried; null for whole-market snapshot
`type`	No	Pricing mode queried (vast-ai only): ondemand, bid, reserved
`market`	No	Market id, e.g. compute-spot (whole-market only)
`offers`	No	Per-offer asks; stable keys include usd_per_gpu_hr, provider, gpu, kind, observed_at
`source`	No	Upstream source id (aggregated sources only)
`classes`	No	Per-class aggregates (whole-market snapshot only)
`provenance`	No	Provenance: object for vast-ai, string for aggregated sources
`observed_at`	No	ISO-8601 observation timestamp
`generated_at`	No	ISO-8601 snapshot generation timestamp (whole-market only)
`offers_returned`	No
`observation_type`	No	ask = live asks, survey = aggregated survey
`source_attribution`	No	License/attribution (aggregated sources only)

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 21, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "classes": {
+      "description": "Per-class aggregates (whole-market snapshot only)",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "cheapest_rentable": {
+            "anyOf": [
+              {
+                "additionalProperties": {},
+                "type": "object"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "gpu_class": {
+            "type": "string"
+          },
+          "median_price_per_gpu_hour_usd": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "offers_observed": {
+            "type": "number"
+          }
+        },
+        "required": [
+          "gpu_class",
+          "offers_observed",
+          "cheapest_rentable",
+          "median_price_per_gpu_hour_usd"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "generated_at": {
+      "description": "ISO-8601 snapshot generation timestamp (whole-market only)",
+      "type": "string"
+    },
+    "gpu": {
+      "description": "GPU class queried; null for whole-market snapshot",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "market": {
+      "description": "Market id, e.g. compute-spot (whole-market only)",
+      "type": "string"
+    },
+    "observation_type": {
+      "description": "ask = live asks, survey = aggregated survey",
+      "type": "string"
+    },
+    "observed_at": {
+      "description": "ISO-8601 observation timestamp",
+      "type": "string"
+    },
+    "offers": {
+      "description": "Per-offer asks; stable keys include usd_per_gpu_hr, provider, gpu, kind, observed_at",
+      "items": {
+        "additionalProperties": {},
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "offers_returned": {
+      "type": "number"
+    },
+    "provenance": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "additionalProperties": {},
+          "type": "object"
+        }
+      ],
+      "description": "Provenance: object for vast-ai, string for aggregated sources"
+    },
+    "source": {
+      "description": "Upstream source id (aggregated sources only)",
+      "type": "string"
+    },
+    "source_attribution": {
+      "description": "License/attribution (aggregated sources only)",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "type": {
+      "description": "Pricing mode queried (vast-ai only): ondemand, bid, reserved",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changed1 schema field changedSep 21, 2026

addedInput schema / properties / source

Added value: +{
+  "description": "Upstream source (default vast-ai)",
+  "enum": [
+    "vast-ai",
+    "gpurentalprices",
+    "price-book"
+  ],
+  "type": "string"
+}

First observedSep 21, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already cover readOnly, openWorld, idempotent, and non-destructive behavior. The description adds important behavioral context beyond those: listings are 'ephemeral asks, not delivered-cost guarantees', 'no payment required', and source-specific characteristics (e.g., 'vast-ai live asks', 'gpurentalprices daily aggregated survey, CC BY 4.0, ~34 providers', 'price-book manual reference snapshot'). This helps the agent understand result volatility and provenance.

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?

The description is front-loaded with the core purpose and returns format, then systematically explains sources and types. It is slightly dense but every sentence adds either caveat or useful detail. The final sentence about ephemeral asks is concise and important. No filler.

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 read-only query tool with six parameters, zero required, and a full output schema, the description is highly complete. It covers return structure (per-offer provenance), parameter semantics, caveats, and the fact that no payment is needed. The existing output schema handles return-value details, so the description fills behavioral and usage gaps effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics to the enum parameters by explaining what each source and type means in practice (e.g., 'bid = interruptible spot, cheapest but preemptible', 'reserved (vast-ai only)', 'CC BY 4.0, ~34 providers'). It also clarifies the gpu parameter's role in fetching per-class offers vs whole-market snapshots, going beyond the schema's terse 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?

The description states a specific verb ('observes', 'returns') and resource ('P2P GPU compute market') and defines the output as 'cheapest rentable offers per GPU class' in USD/GPU-hr. It clearly differentiates the tool from siblings like compute_history or compute_price_alerts by framing it as a current observation of spot asks rather than historical or alerting behavior.

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?

The description implies when to use the tool: for free, read-only observation of current market prices, with commentary on sources and pricing modes. It does not explicitly mention sibling tools or state when not to use it, but the 'no payment required' and 'ephemeral asks' caveats provide some usage context. This is implied usage, not explicit routing.

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

All agent-embassy 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.