Skip to main content
Glama

compute.wick.pics

by pics.wick.compute
OverviewDiscussionsAdmin

create_limit_order

Place a standing LIMIT ORDER: when the best live fee-adjusted price for gpu (and optional offer_class) trades at or under max_price_per_gpu_hr, the station cuts a signed FILL TICKET naming the exact offer. The station never holds your provider key — the ticket is executed by whoever does: the open-source keyholder sidecar (/agents/#sidecar), your own agent long-polling POST /api/orders/{id}/ticket, or a human with curl. Returns the order with order_secret SHOWN ONCE — it authenticates ticket reads and the fill call for this order only and can rent nothing by itself. Triggers are checked on the poll cadence (~5-min bars, not tick-by-tick); orders expire in 30 days; a ticket lasts ~4 minutes then the order re-arms.

standing=true makes it a STANDING order — compute that survives: after a
live fill the sidecar keeps watching the machine, and when it is preempted
or dies the order re-arms and refills from the CURRENT best offer, up to
max_refills times with cooloff_seconds between death and refill. Honest
limits: this re-provisions the MACHINE, not the WORK (GPU memory is not
portable — resume from your own checkpoints); refills need your sidecar
alive (it is both witness and executor); cancelling stops supervision but
cannot destroy a running machine (the station holds no key). Watchdog:
spend_alert_usd / age_alert_hours fire a "still yours?" webhook once per
machine when the spend ESTIMATE (uptime x price; the provider's bill is
authoritative) or age crosses your line — auto_destroy_budget_usd remains
the hard stop.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
gpuYes
standingNo
max_refillsNo
min_vram_gbNo
offer_classNo
webhook_urlNo
min_gpu_countNo
age_alert_hoursNo
cooloff_secondsNo
spend_alert_usdNo
max_price_per_gpu_hrYes
auto_destroy_budget_usdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / age_alert_hours
      Added value: +{
+  "default": 0,
+  "title": "Age Alert Hours",
+  "type": "number"
+}
    • addedInput schema / properties / spend_alert_usd
      Added value: +{
+  "default": 0,
+  "title": "Spend Alert Usd",
+  "type": "number"
+}
  2. Changed3 schema fields changed
    • addedInput schema / properties / cooloff_seconds
      Added value: +{
+  "default": 120,
+  "title": "Cooloff Seconds",
+  "type": "integer"
+}
    • addedInput schema / properties / max_refills
      Added value: +{
+  "default": 5,
+  "title": "Max Refills",
+  "type": "integer"
+}
    • addedInput schema / properties / standing
      Added value: +{
+  "default": false,
+  "title": "Standing",
+  "type": "boolean"
+}
  3. Added

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and exceeds it: it discloses key-handling, one-time secret exposure, ticket lifetime, poll cadence, 30-day expiry, re-arm semantics, watchdog webhooks, and hard-stop budget behavior. This is exceptional transparency for a financial mutation tool.

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 justified by the tool's complexity. It front-loads the core mechanism, then expands into standing behavior and watchdog limits. A few phrases are somewhat verbose, but every major paragraph adds essential operational knowledge.

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?

Despite having no output schema and no annotations, the description tells an agent nearly everything needed to call this tool correctly: execution model, security boundaries, timing behaviors, failure modes, and limits. It even explains what the response notably contains (order_secret shown once).

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 0%, so the description must compensate. It explains the core parameters well: max_price_per_gpu_hr, standing, max_refills, cooloff_seconds, spend_alert_usd, age_alert_hours, auto_destroy_budget_usd, and offer_class. However, min_vram_gb, min_gpu_count, and webhook_url are not explicitly mapped to their schema fields.

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 opens with a specific verb and resource: 'Place a standing LIMIT ORDER' with a precise price condition. It distinguishes itself from sibling order tools by detailing the fill-ticket mechanism and sidecar execution path rather than just saying 'create an order.'

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 gives strong context about when standing mode is appropriate and how re-arming works, but it never explicitly contrasts this tool with immediate-rental siblings like rent_best or renter_offer, nor states when NOT to use it. Usage is implied clearly but alternatives are not named.

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

All compute.wick.pics toolsInspect
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