Rokha

What the free tier includes

free_tier_status

Read-only

THE FREE TIER — what anyone gets on Rokha each UTC day, read from the one definition the gates enforce. 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. Every refusal names both doors. Answers the same day as data under per_day; signed in, your own questions and runs left. Public, no login. REST twin: GET /api/free-tier (signed in: GET /api/free-tier/me)

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`line`	No
`tier`	Yes
`doors`	Yes	The doors: the month's price and rails, the hold, the pricing and publish URLs.
`resets`	No
`studio`	Yes	What the Lab gets per day.
`per_day`	Yes	The same day as data: anonymous, signed_in_free, studio, resets.
`summary`	Yes
`includes`	No
`anonymous`	Yes	What a caller with no account gets per day.
`free_doors`	No	{mcp_listings, published_rigs, agents, plain_skills, per}
`upgrade_adds`	No
`signed_in_free`	Yes	What a free account gets per day, publish caps included.
`questions_per_day`	No
`questions_left_today`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 4, 2026

addedOutput schema / properties

Added value: +{
+  "anonymous": {
+    "description": "What a caller with no account gets per day.",
+    "type": "object"
+  },
+  "doors": {
+    "description": "The doors: the month's price and rails, the hold, the pricing and publish URLs.",
+    "type": "object"
+  },
+  "free_doors": {
+    "description": "{mcp_listings, published_rigs, agents, plain_skills, per}",
+    "type": "object"
+  },
+  "includes": {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  "line": {
+    "type": "string"
+  },
+  "per_day": {
+    "description": "The same day as data: anonymous, signed_in_free, studio, resets.",
+    "type": "object"
+  },
+  "questions_left_today": {
+    "type": [
+      "integer",
+      "null"
+    ]
+  },
+  "questions_per_day": {
+    "type": [
+      "integer",
+      "null"
+    ]
+  },
+  "resets": {
+    "type": "string"
+  },
+  "signed_in_free": {
+    "description": "What a free account gets per day, publish caps included.",
+    "type": "object"
+  },
+  "studio": {
+    "description": "What the Lab gets per day.",
+    "type": "object"
+  },
+  "summary": {
+    "type": "string"
+  },
+  "tier": {
+    "enum": [
+      "free",
+      "paid"
+    ],
+    "type": "string"
+  },
+  "upgrade_adds": {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  }
+}

addedOutput schema / required

Added value: +[
+  "tier",
+  "anonymous",
+  "signed_in_free",
+  "studio",
+  "doors",
+  "per_day",
+  "summary"
+]

Changed1 schema field changedNov 2, 2026

changedOutput schema / (root)

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

AddedOct 4, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds real context beyond that: no auth is needed for the public call, the signed-in form returns your own remaining questions and runs, and results are keyed under `per_day`. It also explains that every refusal names both upgrade doors, which tells the agent how this data relates to gate errors. It does not describe caching, rate limits, or freshness beyond 'each UTC day'.

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 single dense run-on block of pricing and quota copy — including card/USDC/SOL payment rails and a $29.99 price — most of which duplicates what the tool returns and what the existing output schema already carries. The actual call semantics (public, no login, per_day keying, REST twin) are buried at the very end rather than front-loaded.

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?

For a parameterless read tool with annotations and an output schema, the description covers auth requirements, the anonymous vs signed-in split, and the shape of the returned limits, which is enough for an agent to call it correctly. The tier/pricing exposition is more than needed rather than less, so nothing essential is missing.

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?

There are zero input parameters, so the baseline is 4. The description does clarify that the only variation in behavior is auth state (anonymous vs signed in), which is the one meaningful input distinction even though it is not modeled as a parameter.

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 resource: the canonical free-tier definition that the gates enforce, broken down by anonymous, signed-in, and Lab tiers, with a REST twin named (GET /api/free-tier). It is clearly a read-only informational lookup rather than an action, but it never distinguishes itself from siblings like subscription_status, studio_doors, or tools_catalog, which an agent could plausibly confuse it with.

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 only implied: an agent infers it should call this to learn limits before attempting a run, build, or publish. The description says 'Public, no login' and notes the signed-in variant, which hints at when each form applies, but it gives no explicit when-to-use, when-not-to-use, or alternative-tool routing against subscription_status or product_get.

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

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.