Rokha

Run a saved Rig for real

rig_run

RUN a rig, for real, right now. Without this an outside agent could AUTHOR a rig, schedule it and hang a webhook on it — but never run one on demand, and so never test the thing it just built. Name the rig by rig_id (one you own or adopted) OR by provider_id + external_id (a published listing — this adopts YOUR OWN copy first, then runs it, which also heals a stale adopted copy). input is whatever the rig's input declares (a token address, a URL, a query). The run bills the CALLER's own allowance and executes REAL tools — including money steps if the rig has them and you have granted a mandate, so read the rig before running someone else's. Returns immediately; results land as TRACES. Every answer carries run_id and stage_url: a hosted rokha.ai page showing this run's dashboard to whoever may read the run — hand it to your user. wait:true + render:true also returns stage_html (the dashboard as one self-contained HTML document, <=200 KB) to render yourself in a sandboxed frame (iframe sandbox=allow-scripts, never allow-same-origin); GET /api/rigs/runs/<run_id>/stage returns {title, html} later. A PAID rig answers 402 purchase_required until you hold it: product_get shows the price and any PACK that carries it; product_checkout buys it (x402 / usdc / sol, no browser). Free to start: a signed-in account runs 5 a day (model steps on your own model key); past them a run pack is 100 runs for $1 (product_checkout, its product_id is in free_tier_status) and the Lab month (subscribe) is full access. Requires Authorization: Bearer or an rk_ key.

Input Schema

Name	Required	Description
`wait`	No	true = hold the call until the run finishes (up to ~5 min) and return its output, steps, status and trace_id in one answer. Default false: returns at once, results land as traces (trace_search by rig_id).
`input`	No	What the run works on. Omit only for input-less rigs.
`render`	No	With wait:true: also return stage_html, the run's dashboard as one self-contained HTML document (<=200 KB), to render in a sandboxed frame. stage_url is always returned.
`rig_id`	No	UUID of a rig you own or adopted.
`external_id`	No	With provider_id.
`provider_id`	No	With external_id: run a PUBLISHED listing (adopts your own copy first).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}

Changed1 schema field changedOct 15, 2026

addedInput schema / properties / render

Added value: +{
+  "description": "With wait:true: also return stage_html, the run's dashboard as one self-contained HTML document (<=200 KB), to render in a sandboxed frame. stage_url is always returned.",
+  "type": "boolean"
+}

Changed1 schema field changedSep 26, 2026

addedInput schema / properties / wait

Added value: +{
+  "description": "true = hold the call until the run finishes (up to ~5 min) and return its output, steps, status and trace_id in one answer. Default false: returns at once, results land as traces (trace_search by rig_id).",
+  "type": "boolean"
+}

First observedSep 26, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the readOnlyHint=false / destructiveHint=false annotations: discloses that the run bills the CALLER's allowance, executes REAL tools including money steps requiring a granted mandate, returns 402 purchase_required for paid rigs, and is rate-limited to 5 free runs/day with pack and subscription pricing. It also states the authentication requirement (Bearer JWT or rk_ key) and the async trace landing behavior. Nothing here contradicts the annotations — the write-capable profile matches readOnlyHint=false.

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?

Front-loads the action and is logically ordered, but it is markedly overlong for a 6-parameter tool: the wait/render/stage_html contract is restated from the schema, and a pricing/marketing passage (run packs, Lab month, x402/usdc/sol) crowds the core invocation guidance. Formatting artifacts and padded spacing further hurt scanability.

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 tool that mutates state, bills money and runs asynchronously, the description covers everything an agent needs: addressing, input semantics, sync vs async result paths, the 402 paid-rig recovery route, auth, quotas, and the security constraint on rendering returned HTML. An output schema exists, so return-value detail is appropriately left to it.

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, but the description adds real meaning: what 'input' means in practice ('a token address, a URL, a query'), that provider_id+external_id 'adopts YOUR OWN copy first, then runs it, which also heals a stale adopted copy', and the sandbox constraints for rendering stage_html. Only minor redundancy with the schema keeps it from a 5.

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 ('RUN a rig, for real, right now') and distinguishes itself from the authoring/scheduling siblings by noting that without it an agent could 'AUTHOR a rig, schedule it and hang a webhook on it' but never execute it. The rig_id vs provider_id+external_id addressing modes make the invocation target unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit about when to use each addressing mode (owned/adopted rig vs published listing), warns to 'read the rig before running someone else's' when money steps are possible, and routes paid-rig situations to product_get / product_checkout / free_tier_status by name. It also says when not to expect synchronous output (wait:false → results land as traces).

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

All Rokha tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.