Agent Embassy

Compute Spot Prices

compute_spot_prices

GPU asks, not quotes: one timestamped snapshot; asks may vanish. Observes only. Omit gpu = full snapshot; type defaults ondemand. Sealed: compute_spot_sealed. GET the paid_url with an x402 v2 PAYMENT-SIGNATURE header carrying the USDC authorization. Paid tool — $0.25 per snapshot, USDC on Base or Arbitrum One. Paid URL: https://aemb.pro/v1/markets/compute/spot.

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

Input Schema

Name	Required	Description
`gpu`	No	Optional GPU model filter, e.g. 'H100 SXM'
`type`	No	Offer type: ondemand (fixed price), bid (interruptible auction — shown price is the bid floor), or reserved (longer commitment)
`max_gpus`	No	Maximum GPU count per offer; integer 1..64
`min_gpus`	No	Minimum GPU count per offer; integer >= 1
`verified`	No	When true, only verified hosts; when false, only unverified hosts
`max_results`	No	Max offers to return; integer 1-25
`min_reliability`	No	Minimum host reliability 0..1 (inclusive); hosts below it are excluded

Output Schema

Name	Required	Description
`how`	Yes	How to pay: GET the paid_url with an x402 v2 PAYMENT-SIGNATURE header carrying the USDC authorization
`tool`	Yes	Tool name: compute_spot_prices
`asset`	Yes	Settlement asset
`price`	Yes	Exact price, e.g. "$0.25"
`networks`	Yes	EVM CAIP-2 network ids accepted
`paid_url`	Yes	x402-paid HTTPS URL to GET (with query params) for the market snapshot
`facilitator`	Yes	x402 facilitator
`payment_required`	Yes	Always true: this MCP tool is a payment pointer; the tool itself is monetized via x402.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 6, 2026

addedInput schema / properties / max_gpus

Added value: +{
+  "description": "Maximum GPU count per offer; integer 1..64",
+  "maximum": 64,
+  "minimum": 1,
+  "type": "integer"
+}

changedInput schema / properties / type / description

Previous value: -"Offer type filter: ondemand, bid, or reserved"New value: +"Offer type: ondemand (fixed price), bid (interruptible auction — shown price is the bid floor), or reserved (longer commitment)"

Changed6 schema fields changedSep 24, 2026

addedInput schema / properties / gpu / description

Added value: +"Optional GPU model filter, e.g. 'H100 SXM'"

addedInput schema / properties / max_results / description
```
Added value: +"Max offers to return; integer 1-25"
```

addedInput schema / properties / min_gpus / description

Added value: +"Minimum GPU count per offer; integer >= 1"

addedInput schema / properties / min_reliability

Added value: +{
+  "description": "Minimum host reliability 0..1 (inclusive); hosts below it are excluded",
+  "maximum": 1,
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / type / description

Added value: +"Offer type filter: ondemand, bid, or reserved"

addedInput schema / properties / verified / description

Added value: +"When true, only verified hosts; when false, only unverified hosts"

First observedSep 23, 2026

TDQS

A4/5.0

Behavior4/5

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

Goes well beyond the annotations by disclosing the payment model ($0.25/snapshot, USDC on Base or Arbitrum One), the required x402 v2 PAYMENT-SIGNATURE auth header, and the ephemeral nature of asks. It also explains the non-readOnly behavior implicitly via the paid call. It does not reconcile 'Observes only' with readOnlyHint=false explicitly, but the payment disclosure accounts for it.

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?

Dense and front-loaded — purpose first, then filtering semantics, then the sibling alternative, then payment/auth mechanics. Nearly every clause earns its place, though the fragmentary style ('GPU asks, not quotes') is slightly cryptic and costs a point.

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 values need not be described; the description covers filtering behavior, the sealed alternative, the paid URL, and the auth mechanism, which is what an agent needs to call it correctly. The only soft spot is not stating the consequence of the readOnlyHint=false annotation, though the payment note covers the practical effect.

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 baseline is 3, and the description adds two facts not in the schema: that omitting gpu returns a full snapshot and that type defaults to ondemand. The remaining five filter parameters are left to the schema, which documents them fully.

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 the resource and scope concretely — GPU spot ask prices as a single timestamped snapshot — and distinguishes itself from compute_spot_sealed by name. The verb is implicit (the title carries 'Compute Spot Prices'), and the telegraphic 'GPU asks, not quotes' phrasing takes a beat to parse, so it falls short of a clean 5.

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 practical selection context: 'Omit gpu = full snapshot; type defaults ondemand' and routes to the alternative sibling 'Sealed: compute_spot_sealed'. It also discloses the paid nature, which affects whether an agent should call it. It never explicitly states when NOT to use it, so 4 rather than 5.

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.

Resources

Need Help?