Lantern Works GPU Prices: daily GPU rental price comparison

estimate_job_cost

Read-only

Cost of one GPU job (not cost per hour) among tracked providers, cheapest current compute subtotal first.

gpu_family (e.g. 'H100', 'A100 80GB') or its alias gpu (same name compare_gpu_prices uses) is required; if both are given they must match, else invalid_argument. gpus_per_job defaults to 1. Ranking matches compare_gpu_prices' default: fresh rows first (a degraded price, older than 48 h, is shown and flagged but never ranked first while a fresh one exists), fresh on-demand before community/marketplace rows, then compute subtotal ascending; the summary names any cheaper fresh rate ranked lower. If no fresh price exists, stale_fallback=true and the summary says the top row is not a current price.

You supply the duration: job_hours, OR work_units plus throughput_units_per_gpu_hour from your own benchmark (job_hours = work_units / (throughput x gpus_per_job)). If you give workload + work_units but no throughput, a directly applicable published figure (closed-division MLPerf Inference, exact GPU variant, inference only) is used: throughput_basis='published_benchmark' with throughput_source {url, quote, date, benchmark, derived, caveats}; your throughput always wins. Otherwise not_found 'missing: throughput for {gpu}'. Whole-instance billing: instances = ceil(gpus_per_job / gpus_per_instance), all allocated GPUs billed (9 GPUs on an 8-GPU-only offer bill 16). Reserved and held-stale rates are never ranked; spot/interruptible only if allow_interruptible. Each result has rate_id, source_url, verified_at, data_age_hours/degraded/stale. Response has assumptions, citations, missing_costs, budget_verdict (unresolved: extras unknown) and a quote_id. Compute subtotal only.

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

Input Schema

Name	Required	Default
`gpu`	No
`mode`	No	full
`top_n`	No
`region`	No
`workload`	No
`job_hours`	No
`gpu_family`	No
`work_units`	No
`min_vram_gb`	No
`gpus_per_job`	No
`runs_per_month`	No
`max_data_age_hours`	No
`allow_interruptible`	No
`throughput_units_per_gpu_hour`	No

Output Schema

Name	Required	Description
`ok`	Yes
`mode`	No
`error`	No
`receipt`	No
`results`	No
`quote_id`	No
`issued_at`	No
`quote_basis`	No
`budget_verdict`	No
`referral_disclosure`	No	One-line referral disclosure, present whenever the result names a provider; each provider-naming item then has tracked_url (tagged /go/ redirect).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 11, 2026

addedOutput schema / properties / referral_disclosure

Added value: +{
+  "description": "One-line referral disclosure, present whenever the result names a provider; each provider-naming item then has tracked_url (tagged /go/ redirect).",
+  "type": "string"
+}

Changed4 schema fields changedNov 10, 2026
- addedInput schema / properties / gpu
```
Added value: +{
+  "default": null,
+  "type": "string"
+}
```
- addedInput schema / properties / gpu_family / default
```
Added value: +null
```
- addedInput schema / properties / gpus_per_job / default
```
Added value: +1
```
- removedInput schema / required
```
Removed value: -[
-  "gpu_family",
-  "gpus_per_job"
-]
```

Changed1 schema field changedNov 2, 2026

addedOutput schema / properties / receipt

Added value: +{
+  "required": [
+    "receipt_version",
+    "tool",
+    "quote_id",
+    "lines",
+    "feed_revision",
+    "receipt_sha256"
+  ],
+  "type": "object"
+}

Changed1 schema field changedOct 30, 2026
- addedInput schema / properties / region
```
Added value: +{
+  "default": null,
+  "type": "string"
+}
```
Changed1 schema field changedOct 30, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
Changed2 schema fields changedOct 29, 2026
- addedOutput schema / properties / results / items / properties / availability / properties / basis
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / results / items / properties / availability / properties / source
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```

Changed3 schema fields changedOct 29, 2026

addedOutput schema / properties / results / items / properties / availability

Added value: +{
+  "properties": {
+    "checked_at": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "in_stock": {
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "note": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "status": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": [
+    "object",
+    "null"
+  ]
+}

addedOutput schema / properties / results / items / properties / availability_note
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
addedOutput schema / properties / results / items / properties / in_stock
```
Added value: +{
+  "type": [
+    "boolean",
+    "null"
+  ]
+}
```

AddedOct 29, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations give only readOnlyHint and openWorldHint; the description carries substantial extra behavior: 48h staleness with degraded rows shown-but-not-ranked-first, stale_fallback=true with a summary caveat, reserved/held-stale rates never ranked, spot only when allow_interruptible, and whole-instance billing with ceil() rounding spilling to 16 GPUs. It also discloses the returned fields (rate_id, source_url, verified_at, data_age_hours, budget_verdict, quote_id).

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?

Almost every sentence carries real information, and the headline cost-vs-rate distinction is front-loaded. However, it is a dense wall of text with stacked parentheticals and a dangling fragment ('Compute subtotal only.') at the end that would benefit from tightening.

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?

The output schema means return values needn't be spelled out, yet the description still names key response members. For a 14-parameter, open-world price tool it is quite complete, but the unmentioned pagination/scope params (top_n, region, mode, runs_per_month) leave an agent guessing at their 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?

With 0% schema coverage and 14 params, the description compensates well: gpu_family/gpu alias equivalence and the invalid_argument rule, gpus_per_job default, the job_hours alternative, the work_units/throughput formula, and allow_interruptible's effect are all explained. mode, top_n, region, min_vram_gb, and runs_per_month are left undefined, so gaps remain in an otherwise strong semantic layer.

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?

States a specific verb and resource — 'Cost of one GPU job (not cost per hour)' — and immediately disambiguates from the hourly-price sibling by naming compare_gpu_prices. The scope 'among tracked providers, cheapest current compute subtotal first' tells an agent exactly what it gets back.

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?

Clear about when the published-benchmark fallback applies, when not_found 'missing: throughput' is returned, and that 'your throughput always wins'. It also ties ranking parity to compare_gpu_prices' default. It stops short of explicitly saying 'use compare_gpu_prices instead when you only want per-hour rates', leaving that routing implicit.

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

All Lantern Works GPU Prices: daily GPU rental price comparison tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.