Rokha

The Market

market_search

Read-only

THE MARKET (rokha.ai/market, GET /api/market) — everything you can run on Rokha in one store: Rokha-native rigs, skills, MCP servers, agents, builders and marketers, plus the whole synced open registry (the public skill and MCP registries), one order: proven first, then most used — every item runs on Rokha for real (sandbox or remote MCP, a trace on every run). Browse by aisle (what it is: all · rig · skill · mcp · agent · builder · marketer) and dept (what it is for: all · social · media · research · dev · data · fun); source = all · rokha · registry; sort = popular (default: ready-to-hire capabilities first, then proven first, then installs/stars/uses across every source) · top (most used on Rokha — uses, then users, then last active; registry: proven, then installs, then stars) · live · new · hired (most hired: paid hires, then USDC paid) · qualified (just qualified: the newest passed qualification first); price = any · free · paid (paid = has an active creator product — Buy/Hire); proven = 1 for only what ran end to end; q (≤ 80 chars) ranks title match > tag > description, proven first within ties; limit 1–48 (default 24); pass next_cursor back as cursor for the next page (opaque, signed, bound to the query). Each item: id, kind, source, title, subtitle, handle, href, image (product art or null), tagline, link, department, tags, official (House), architect (the founder's build), proven, live, new, stats {uses_total, users_total, installs, stars, reach}, price {usd, model, product_id} or null, cta + cta_secondary. Also total (null when q is set) and facets (aisle + department counts). Pass ids (a list of item ids) for exactly those items in that order — the Market view of a set of picks is https://rokha.ai/market?ids=. Never an owner wallet, email or runner identity. Public, no auth, cached 30 s. Curated shelves: GET /api/market/shelves.

Input Schema

Name	Required	Description
`q`	No	Search words; omit to browse.
`ids`	No	Exactly these items (each one's `id` from an earlier result), in this order — every other filter is ignored, no cursor. Recommending tools? Hand the person ONE Market view of your picks: https://rokha.ai/market?ids=<id1>,<id2>,… (ids URL-encoded, comma-joined).
`dept`	No	What it is for; default all.
`hire`	No	Only capabilities an agent can be HIRED for (proven + priced; each item's hire = {from_cents, agents}). Default off — hireable items lead the default order anyway.
`sort`	No	Order; default popular = ready-to-hire capabilities first, then proven first, then installs/stars/uses across every source (one order across Rokha and the open registry); top = most used on Rokha; hired = most hired (paid hires, then USDC paid, then uses), the never-hired after in top order; qualified = just qualified (newest passed qualification of a priced agent first), the rest in popular order.
`aisle`	No	What it is; default all.
`limit`	No	Items per page; default 24.
`price`	No	Default any.
`cursor`	No	The previous page's next_cursor.
`proven`	No	Only what ran end to end on Rokha.
`source`	No	Rokha-native, the open registry, or both; default all.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 4, 2026

changedInput schema / properties / dept / enum

Previous value: -[
-  "all",
-  "trading",
-  "social",
-  "media",
-  "research",
-  "dev",
-  "data",
-  "fun"
-]New value: +[
+  "all",
+  "social",
+  "media",
+  "research",
+  "dev",
+  "data",
+  "fun"
+]

Changed1 schema field changedNov 2, 2026

changedOutput schema / (root)

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

Changed2 schema fields changedOct 19, 2026

addedInput schema / properties / ids

Added value: +{
+  "description": "Exactly these items (each one's `id` from an earlier result), in this order — every other filter is ignored, no cursor. Recommending tools? Hand the person ONE Market view of your picks: https://rokha.ai/market?ids=<id1>,<id2>,… (ids URL-encoded, comma-joined).",
+  "items": {
+    "maxLength": 300,
+    "type": "string"
+  },
+  "maxItems": 48,
+  "type": "array"
+}

changedInput schema / properties / sort / description

Previous value: -"Order; default popular = ready-to-hire capabilities first, then one order across Rokha and the open registry (installs, stars, uses); top = most used on Rokha; hired = most hired (paid hires, then USDC paid, then uses), the never-hired after in top order; qualified = just qualified (newest passed qualification of a priced agent first), the rest in popular order."New value: +"Order; default popular = ready-to-hire capabilities first, then proven first, then installs/stars/uses across every source (one order across Rokha and the open registry); top = most used on Rokha; hired = most hired (paid hires, then USDC paid, then uses), the never-hired after in top order; qualified = just qualified (newest passed qualification of a priced agent first), the rest in popular order."

Changed2 schema fields changedOct 16, 2026

changedInput schema / properties / sort / description

Previous value: -"Order; default popular = one order across Rokha and the open registry (installs, stars, uses); top = most used on Rokha."New value: +"Order; default popular = ready-to-hire capabilities first, then one order across Rokha and the open registry (installs, stars, uses); top = most used on Rokha; hired = most hired (paid hires, then USDC paid, then uses), the never-hired after in top order; qualified = just qualified (newest passed qualification of a priced agent first), the rest in popular order."

changedInput schema / properties / sort / enum

Previous value: -[
-  "popular",
-  "top",
-  "live",
-  "new"
-]New value: +[
+  "popular",
+  "top",
+  "live",
+  "new",
+  "hired",
+  "qualified"
+]

Changed1 schema field changedOct 16, 2026

addedInput schema / properties / hire

Added value: +{
+  "description": "Only capabilities an agent can be HIRED for (proven + priced; each item's hire = {from_cents, agents}). Default off — hireable items lead the default order anyway.",
+  "type": "boolean"
+}

Changed2 schema fields changedOct 15, 2026

changedInput schema / properties / sort / description

Previous value: -"Order; default top."New value: +"Order; default popular = one order across Rokha and the open registry (installs, stars, uses); top = most used on Rokha."

changedInput schema / properties / sort / enum

Previous value: -[
-  "top",
-  "live",
-  "new"
-]New value: +[
+  "popular",
+  "top",
+  "live",
+  "new"
+]

AddedOct 12, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, but the description adds material behavior on top: 'Public, no auth, cached 30 s', the cursor is 'opaque, signed, bound to the query', `total` is null when q is set, and facets are returned. It also discloses a privacy boundary ('Never an owner wallet, email or runner identity') and notes that every item runs for real with a trace, which no structured field conveys.

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?

It is front-loaded with the tool's identity, which is good, but the body is one dense semicolon-chained block that enumerates all eleven parameters and then restates the full item payload. The item-field list largely duplicates the output schema, and the sort/ids semantics repeat the schema descriptions verbatim, so several sentences do not earn their place.

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 an 11-parameter, zero-required browse tool this covers everything an agent needs: filter vocabulary, ordering semantics, pagination mechanics, auth and caching posture, the `ids` shortcut with a shareable URL pattern, and a pointer to the shelves endpoint. The output schema exists, so the item enumeration is redundant rather than necessary, but nothing important is absent.

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 100%, so the baseline would be 3, but the description adds meaning the schema does not: `q` ranks 'title match > tag > description' with proven first in ties, `paid` means 'has an active creator product — Buy/Hire', and `proven` means ran end to end. Some of the sort/ids text is near-duplicated from the schema descriptions, which caps it at 4 rather than 5.

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 opens with a concrete identity: 'everything you can run on Rokha in one store' and enumerates what that includes (rigs, skills, MCP servers, agents, builders, marketers) plus the synced open registry. That gives an agent a clear sense of scope and implicitly supersedes narrower siblings like registry_search and rig_search. It never names a sibling tool explicitly to route against, so it stops just short of a 5.

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

Usage Guidelines4/5

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

Usage context is unusually rich: 'omit q to browse', pass next_cursor back as cursor, 'pass ids ... every other filter is ignored, no cursor', and defaults for every filter (limit 24, sort popular, hire default off). What is missing is explicit when-to-use-this-vs-that guidance against siblings such as registry_search or tools_catalog, which the agent must infer from the 'everything in one store' framing.

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.

The Market

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources