Lantern Works GPU Prices: daily GPU rental price comparison

optimize_agent_stack

Read-only

Estimate a monthly stack cost from a short description of the agent being built.

description: free text, e.g. 'scrapes 20k JS pages/month via 5 GB residential proxies, 3k search queries, summarizes with an LLM, budget $300/mo'. Parsed deterministically (keywords/regex, no LLM) into components: gpu, scraping, proxy, search, llm_api, email, hosting, database, monitoring. Optional fields override the parse: gpu_hours (GPU-hours/month), gpu_model ('H100', 'A100', 'RTX 4090'), model_size_b (billions of params; sets a minimum VRAM using FP16 x 1.2), scrape_pages, js_rendering, proxy_gb, search_queries, emails_sent, llm_api, monthly_budget_usd. Each component gets the cheapest option with a cited price among tracked providers, with calc, source_url, verified_at, referral_disclosure (set when the link is a referral link) and manual-signup notes. Components with no cited price say 'no sourced price tracked' (nothing is estimated). Totals show the math and say whether they are complete. Pulled listings are excluded. Every option has data_age_hours, degraded (> 48 h) and stale (> 7 days); max_data_age_hours drops older options (excluded_too_old counts them). Same data as optimize_stack, compare_gpu_prices and the deal feed.

Input Schema

Name	Required	Default
`mode`	No	full
`llm_api`	No
`proxy_gb`	No
`workload`	No
`gpu_hours`	No
`gpu_model`	No
`description`	No
`emails_sent`	No
`js_rendering`	No
`model_size_b`	No
`scrape_pages`	No
`search_queries`	No
`max_data_age_hours`	No
`monthly_budget_usd`	No
`exclude_manual_signup`	No

Output Schema

Name	Required	Description	Default
`ok`	Yes
`mode`	No
`error`	No
`lines`	No
`quote_id`	No
`issued_at`	No
`quote_basis`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 29, 2026

addedOutput schema / properties / lines / items / properties / alternatives / 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 / lines / items / properties / alternatives / items / properties / availability_note
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
addedOutput schema / properties / lines / items / properties / alternatives / items / properties / in_stock
```
Added value: +{
+  "type": [
+    "boolean",
+    "null"
+  ]
+}
```
addedOutput schema / properties / lines / items / properties / availability_note
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```

addedOutput schema / properties / lines / items / properties / choice / 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 / lines / items / properties / choice / properties / availability_note
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
addedOutput schema / properties / lines / items / properties / choice / properties / in_stock
```
Added value: +{
+  "type": [
+    "boolean",
+    "null"
+  ]
+}
```

Changed6 schema fields changedOct 29, 2026

changedOutput schema / else / required

Previous value: -[
-  "ok",
-  "mode",
-  "lines",
-  "monthly_estimate_usd",
-  "estimate_is_complete"
-]New value: +[
+  "ok",
+  "mode",
+  "lines",
+  "monthly_estimate_usd",
+  "estimate_is_complete",
+  "quote_id",
+  "issued_at"
+]

changedOutput schema / properties / error / properties / code / enum

Previous value: -[
-  "invalid_argument",
-  "invalid_cursor",
-  "not_found",
-  "feed_unavailable",
-  "feed_invalid",
-  "upstream_unavailable",
-  "internal_error"
-]New value: +[
+  "invalid_argument",
+  "invalid_cursor",
+  "cursor_expired",
+  "not_found",
+  "feed_unavailable",
+  "feed_invalid",
+  "upstream_unavailable",
+  "internal_error"
+]

addedOutput schema / properties / issued_at

Added value: +{
+  "format": "date-time",
+  "type": "string"
+}

addedOutput schema / properties / lines / items / properties

Added value: +{
+  "alternatives": {
+    "items": {
+      "properties": {
+        "rate_id": {
+          "pattern": "^r_[0-9a-f]{12}$",
+          "type": "string"
+        }
+      },
+      "required": [
+        "rate_id"
+      ],
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "type": "array"
+  },
+  "choice": {
+    "properties": {
+      "rate_id": {
+        "pattern": "^r_[0-9a-f]{12}$",
+        "type": "string"
+      }
+    },
+    "required": [
+      "rate_id"
+    ],
+    "type": [
+      "object",
+      "null"
+    ]
+  }
+}

addedOutput schema / properties / quote_basis
```
Added value: +{
+  "type": "object"
+}
```

addedOutput schema / properties / quote_id

Added value: +{
+  "pattern": "^q_[0-9a-f]{20}$",
+  "type": "string"
+}

First observedOct 29, 2026

TDQS

A4/5.0

Behavior5/5

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

With only readOnlyHint and openWorldHint annotations, the description carries substantial behavioral detail: deterministic keyword/regex parsing with no LLM, cheapest cited option per component, 'no sourced price tracked' for unsourced components, totals showing math, exclusion of pulled listings, referral disclosure, manual-signup notes, and data freshness/degraded/stale thresholds.

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 long but front-loads the core purpose and then provides parameter and behavior details appropriate for a 15-parameter tool. Some sections are dense and could be more structured, but the length is largely justified by the tool's complexity.

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?

An output schema exists, so return-format explanation is not strictly required, though the description usefully previews components and totals. For a read-only, open-world estimation tool with 0% schema description coverage, the description is fairly complete, but missing semantics for mode, workload, and exclude_manual_signup leave small gaps.

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 description coverage is 0%, so the description must compensate. It explains most parameters clearly (description, gpu_hours, gpu_model, model_size_b, scrape_pages, js_rendering, proxy_gb, search_queries, emails_sent, llm_api, monthly_budget_usd, max_data_age_hours) but leaves mode, workload, and exclude_manual_signup undefined.

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 verb and resource: 'Estimate a monthly stack cost from a short description of the agent being built.' It also notes the same data as optimize_stack, compare_gpu_prices, and the deal feed, but does not explicitly differentiate when to choose this over optimize_stack.

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 implied by 'from a short description of the agent being built' and the optional override fields, but there is no explicit when-to-use guidance or when to prefer sibling tools like optimize_stack. The mention of shared data with siblings adds context but not selection criteria.

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

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.