Rokha

Studio Doors

studio_doors

Read-only

WHAT ROKHA COSTS. Rokha is the Agent Runtime and Marketplace — build tools, run them for real, sell or hire them. No platform payouts. THREE RUNGS: FREE, signed in (an agent signs in with a wallet over MCP) — 5 runs a day of tools on Rokha's runtime, model steps on your own key; PAY PER RUN — a run pack, 100 runs for $1 (x402, USDC, SOL or card); THE LAB ($29.99 a month, card, USDC or SOL) — full access to everything: the runtime, the Lab, publishing, schedules, Hunt and Mark Check, voice; model steps on your own keys. No trial and no one-time license. FREE, per day: Free, no account: talk to Rokha (10 questions a day — the same taste signed in) and read everything public — the Market, every listing, public runs and traces, finished hunts and saved marks; no runs without an account (sign in free); no builds, hunts, marks or web searches without the Lab. Free, signed in: 10 questions a day, 5 runs a day (tool steps on Rokha's sandbox, model steps on your own model key), and listing — claim a page and publish 1 agent, 3 rigs, 2 MCP servers and 3 plain skills in all; no builds, Hunts or Mark Checks without the Lab; more runs: a run pack, 100 runs for $1, or the Lab. The Lab — the Lab, $29.99 a month (card, USDC or SOL) — full access to everything: 300 runs, 50 Hunts and 100 Mark Checks a day, no publish caps, every model step on your own model key.. Claiming a page and an affiliate code are free. Everything you publish shows on the market right away, ranked by use, with a trace on every run. Sell your work for card, USDC or SOL and keep 80% (sellers are paid in USDC); refer a Lab buyer for 25% of their first month. Every fee: https://rokha.ai/fees. Returns the live prices — never quote one from memory. Public, no auth.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`docs`	Yes
`free`	Yes
`studio`	Yes	{sales_open, sales_note, month_usd, license_sales_open, trial, keys, rails}
`network`	No	How the market works: how, url, join, steps, board, rank, agents.
`posture`	No
`summary`	No
`free_until`	No
`free_window_open`	No
`free_window_terms`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 4, 2026

changedOutput schema / properties / network / description

Previous value: -"How the market works: how, url, join, steps, board, rank, agents, retired."New value: +"How the market works: how, url, join, steps, board, rank, agents."

removedOutput schema / properties / retired_tiers
```
Removed value: -{
-  "type": "string"
-}
```

Changed2 schema fields changedNov 4, 2026

addedOutput schema / properties

Added value: +{
+  "docs": {
+    "type": "string"
+  },
+  "free": {
+    "type": "string"
+  },
+  "free_until": {
+    "type": [
+      "string",
+      "null"
+    ]
+  },
+  "free_window_open": {
+    "type": "boolean"
+  },
+  "free_window_terms": {
+    "type": "string"
+  },
+  "network": {
+    "description": "How the market works: how, url, join, steps, board, rank, agents, retired.",
+    "type": "object"
+  },
+  "posture": {
+    "type": "string"
+  },
+  "retired_tiers": {
+    "type": "string"
+  },
+  "studio": {
+    "description": "{sales_open, sales_note, month_usd, license_sales_open, trial, keys, rails}",
+    "type": "object"
+  },
+  "summary": {
+    "type": "string"
+  }
+}

addedOutput schema / required

Added value: +[
+  "studio",
+  "free",
+  "docs"
+]

Changed1 schema field changedNov 2, 2026

changedOutput schema / (root)

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

First observedSep 26, 2026

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that — "Public, no auth" and the fact that values are live and must not be cached or recalled — which is exactly the kind of behavioral note annotations cannot carry. It stops short of describing freshness window or how the prices are structured, and has output schema coverage for return values.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a wall of marketing prose with duplicated content (the free-tier rules are stated twice in near-identical form), stray typos ("own model key.."), and the operative sentence stranded at the very end. Front-loading is absent — an agent must read to the last line to learn what the tool does. Only the pricing detail itself arguably has value, and even that is redundant with the return payload.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Because an output schema exists, the description need not explain the returned price structure, and it does correctly flag that the values are live and require no authentication. However, for a zero-parameter, read-only lookup, the description is simultaneously over-long on irrelevant tier marketing and under-clear on the one thing that matters: what exactly gets returned and when an agent should call this versus other billing-related siblings.

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?

The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. The schema is empty and fully specified, and the description correctly presents this as a context-free lookup with no inputs to supply.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The actual function appears only in the final sentence: "Returns the live prices — never quote one from memory." Everything before it is product copy about tiers and fees, and the name/title ("studio_doors") give no clue about pricing. An agent can eventually infer the tool returns current pricing, but the verb+resource is buried rather than stated up front, and no sibling (product_get, subscription_status, free_tier_status) is distinguished.

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?

"Never quote one from memory" is an implicit directive to call this tool instead of recalling prices, which is real but thin guidance. There is no statement of when to prefer it over product_get, subscription_status, or free_tier_status, and no when-not conditions. Usage is implied rather than specified.

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.