Rokha
REMOTE · ROKHA.AI · SCANNED OCT 3
Search a registry of agent skills and MCP servers, then run them for real. No install, traced.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security94
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token. View diagnostics → Pass
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
- The authorisation server offers only Dynamic Client Registration (RFC 7591), which MCP 2026-07-28 deprecated in favour of Client ID Metadata Documents. View diagnostics → Partial
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability78
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (good).Pass
- Context-footprint check failed: tool/resource definitions use about 35100 tokens (~166/item across 211 items; 211 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management12
- Stability check failed: schema churn in the 7 days we've observed: 11 tool removals, 11 breaking changes, 0 auth/transport breaks, 81 additions. See how to fix → Fail
Tool Coverage88
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 65% of tool parameters carry a description.Partial
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- All 11 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
- An AI judge read all 212 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
How do I install the Rokha MCP server?
Rokha is a hosted endpoint at https://rokha.ai/mcp/jsonrpc, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · rokha.ai
claude mcp add --transport http ai-rokha-rokha 'https://rokha.ai/mcp/jsonrpc'
{
"mcpServers": {
"ai-rokha-rokha": {
"url": "https://rokha.ai/mcp/jsonrpc"
}
}
} {
"servers": {
"ai-rokha-rokha": {
"type": "http",
"url": "https://rokha.ai/mcp/jsonrpc"
}
}
} [mcp_servers.ai-rokha-rokha] url = "https://rokha.ai/mcp/jsonrpc"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"ai-rokha-rokha": {
"type": "remote",
"url": "https://rokha.ai/mcp/jsonrpc",
"enabled": true
}
}
} openclaw mcp add ai-rokha-rokha --url 'https://rokha.ai/mcp/jsonrpc' --transport streamable-http
mcp_servers:
ai-rokha-rokha:
url: "https://rokha.ai/mcp/jsonrpc" {
"McpServers": {
"ai-rokha-rokha": {
"Transport": "http",
"Url": "https://rokha.ai/mcp/jsonrpc"
}
}
} assistant mcp add ai-rokha-rokha -t streamable-http -u 'https://rokha.ai/mcp/jsonrpc'
{
"mcpServers": {
"ai-rokha-rokha": {
"type": "http",
"url": "https://rokha.ai/mcp/jsonrpc"
}
}
} The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 3 Oct 26 0
- Tool “boosts_explain” rewrote its description, which is the text the model reads security
- Tool “carry_brief” rewrote its description, which is the text the model reads security
- Tool “justify_seeds” rewrote its description, which is the text the model reads security
- Tool “network_briefs” rewrote its description, which is the text the model reads security
- Tool “product_set” rewrote its description, which is the text the model reads security
- Tool “seeds_explain” rewrote its description, which is the text the model reads security
- New tool “interface_set” functional
- New tool “platform_interfaces_get” functional
- New tool “room_config_get” functional
- New tool “room_config_set” functional
- “rig_edge” reworded the description of “guard” cosmetic
- 2 Oct 26 +1
- Tool “adspace_bid” rewrote its description, which is the text the model reads security
- Tool “boosts_explain” rewrote its description, which is the text the model reads security
- Tool “carry_brief” rewrote its description, which is the text the model reads security
- Tool “page_claim” rewrote its description, which is the text the model reads security
- Tool “registry_search” rewrote its description, which is the text the model reads security
- Tool “rig_publish” rewrote its description, which is the text the model reads security
- Tool “studio_doors” rewrote its description, which is the text the model reads security
- Tool “wall_mcp_publish” rewrote its description, which is the text the model reads security
- New tool “carry_order” functional
- New tool “carry_order_check” functional
- New tool “creator_earnings” functional
- New tool “fuel_boost” functional
- New tool “fuel_boost_menu” functional
- New tool “fuel_tanks” functional
- New tool “network_brief_get” functional
- New tool “network_brief_set” functional
- New tool “network_briefs” functional
- New tool “network_join” functional
- New tool “network_join_status” functional
- New tool “network_me” functional
- New tool “network_member_report” functional
- New tool “network_members” functional
- New tool “network_my_picks” functional
- New tool “network_pick” functional
- New tool “network_plans” functional
- New tool “network_pot” functional
- New tool “network_referral” functional
- New tool “network_unpick” functional
- New tool “product_checkout” functional
- New tool “product_get” functional
- New tool “product_set” functional
- New tool “purchases_mine” functional
- “registry_search” added an optional parameter “proven” cosmetic
- “registry_search” added an optional parameter “type” cosmetic
- “registry_search” made “query” optional cosmetic
- 1 Oct 26 0
- New tool “fuel_menu” functional
- New tool “fuel_price” functional
- New tool “fuel_spend” functional
- New tool “fuel_status” functional
- 30 Sept 26 0
- New tool “agent_desk” functional
- New tool “signal_feed” functional
- 29 Sept 26 0
- A breaking change shipped without a version bump: still 0.1.0 ▼ security
- New tool “signet_paper_reset”, which the server declares destructive security
- Tool “trace_get” rewrote its description, which is the text the model reads security
- Tool “trace_search” rewrote its description, which is the text the model reads security
- “trace_get” dropped the required parameter “wallet_address” ▼ functional
- New tool “signet_paper_buy” functional
- New tool “signet_paper_positions” functional
- New tool “signet_paper_sell” functional
- New tool “signet_wallet_activity” functional
- “trace_get” added an optional parameter “run_id” cosmetic
- “trace_search” added an optional parameter “node_id” cosmetic
- “trace_search” added an optional parameter “run_id” cosmetic
- “trace_get” reworded the description of “id” cosmetic
- “trace_get” made “id” optional cosmetic
- 28 Sept 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 27 Sept 26 0
- Stability: unverified → fail ▼ security
- A breaking change shipped without a version bump: still 0.1.0 ▼ security
- Tool “bounty_create” was removed ▼ security
- Tool “bounty_list” was removed ▼ security
- Tool “bounty_submit” was removed ▼ security
- Tool “hood_oracle” was removed ▼ security
- Tool “playground_state” was removed ▼ security
- Tool “playground_act” was removed ▼ security
- Tool “playground_join” was removed ▼ security
- Tool “stream_join” was removed ▼ security
- Tool “stream_say” was removed ▼ security
- Tool “aasagenticawesomeskills__compose_stack” rewrote its description, which is the text the model reads security
- Tool “aasagenticawesomeskills__diff_stack” rewrote its description, which is the text the model reads security
- Tool “aasagenticawesomeskills__export_selection_evidence” rewrote its description, which is the text the model reads security
- Tool “aasagenticawesomeskills__get_skill” rewrote its description, which is the text the model reads security
- Tool “aasagenticawesomeskills__inspect_selection_evidence” rewrote its description, which is the text the model reads security
- Tool “aasagenticawesomeskills__inspect_stack” rewrote its description, which is the text the model reads security
- Tool “aasagenticawesomeskills__list_skill_files” rewrote its description, which is the text the model reads security
- Tool “aasagenticawesomeskills__read_skill_file” rewrote its description, which is the text the model reads security
- Tool “aasagenticawesomeskills__search_skills” rewrote its description, which is the text the model reads security
- Tool “orbitx__fetch” rewrote its description, which is the text the model reads security
- Tool “orbitx__orbitx_crypto_scan” rewrote its description, which is the text the model reads security
- Tool “orbitx__orbitx_dex_chart” rewrote its description, which is the text the model reads security
- Tool “orbitx__orbitx_get_ath” rewrote its description, which is the text the model reads security
- Tool “orbitx__orbitx_get_balance” rewrote its description, which is the text the model reads security
- Tool “orbitx__orbitx_get_chart” rewrote its description, which is the text the model reads security
- Tool “orbitx__orbitx_get_forensics” rewrote its description, which is the text the model reads security
- Tool “orbitx__orbitx_get_kols” rewrote its description, which is the text the model reads security
- Tool “orbitx__orbitx_get_safety” rewrote its description, which is the text the model reads security
- Tool “orbitx__orbitx_get_signals” rewrote its description, which is the text the model reads security
- Tool “orbitx__orbitx_get_token” rewrote its description, which is the text the model reads security
- Tool “orbitx__orbitx_get_wallet” rewrote its description, which is the text the model reads security
- Tool “orbitx__orbitx_menu” rewrote its description, which is the text the model reads security
- Tool “orbitx__orbitx_screen_tokens” rewrote its description, which is the text the model reads security
- Tool “orbitx__orbitx_search” rewrote its description, which is the text the model reads security
- Tool “orbitx__orbitx_whoami” rewrote its description, which is the text the model reads security
- Tool “orbitx__search” rewrote its description, which is the text the model reads security
- Schema quality: 157 → 179 ▼ functional
- “orbitx__fetch” added a required parameter “id”, so existing callers break ▼ functional
- “orbitx__orbitx_crypto_scan” added a required parameter “mint”, so existing callers break ▼ functional
- “orbitx__orbitx_get_ath” added a required parameter “mint”, so existing callers break ▼ functional
- “orbitx__orbitx_get_chart” added a required parameter “mint”, so existing callers break ▼ functional
- “orbitx__orbitx_get_forensics” added a required parameter “mint”, so existing callers break ▼ functional
- “orbitx__orbitx_get_safety” added a required parameter “mint”, so existing callers break ▼ functional
- “orbitx__orbitx_get_token” added a required parameter “mint”, so existing callers break ▼ functional
- “orbitx__orbitx_screen_tokens” added a required parameter “type”, so existing callers break ▼ functional
- “orbitx__orbitx_search” added a required parameter “q”, so existing callers break ▼ functional
- “orbitx__search” added a required parameter “query”, so existing callers break ▼ functional
- New tool “orbitx__orbitx_dex_listings” functional
- New tool “orbitx__orbitx_gc_focus” functional
- New tool “orbitx__orbitx_gc_history” functional
- New tool “orbitx__orbitx_gc_list” functional
- New tool “orbitx__orbitx_leaderboard” functional
- New tool “orbitx__orbitx_life_account” functional
- New tool “orbitx__orbitx_life_city” functional
- New tool “orbitx__orbitx_life_files” functional
- New tool “orbitx__orbitx_life_list” functional
- New tool “orbitx__orbitx_life_timeline” functional
- New tool “orbitx__orbitx_nft_collections” functional
- New tool “orbitx__orbitx_nft_items” functional
- New tool “orbitx__orbitx_nft_listings” functional
- New tool “orbitx__orbitx_research” functional
- New tool “orbitx__orbitx_social_communities” functional
- New tool “orbitx__orbitx_social_feed” functional
- New tool “orbitx__orbitx_telegram_cmds” functional
- New tool “orbitx__orbitx_telegram_status” functional
- New tool “orbitx__orbitx_vc_link” functional
- New tool “orbitx__orbitx_vc_list” functional
- New tool “orbitx__orbitx_x_connect” functional
- New tool “orbitx__orbitx_x_status” functional
- New tool “orbitx__orbitx_xray” functional
- New tool “rig_publish” functional
- New tool “singularityagent__balance” functional
- New tool “singularityagent__chain_liveness” functional
- New tool “singularityagent__chains” functional
- New tool “singularityagent__decode” functional
- New tool “singularityagent__fees” functional
- New tool “singularityagent__history” functional
- New tool “singularityagent__inspect_exit” functional
- New tool “singularityagent__inspect_payment” functional
- New tool “singularityagent__mesh” functional
- New tool “singularityagent__mint_audit” functional
- New tool “singularityagent__portfolio” functional
- New tool “singularityagent__prove_payment” functional
- New tool “singularityagent__read_contract” functional
- New tool “singularityagent__receipt_art” functional
- New tool “singularityagent__resolve” functional
- New tool “singularityagent__token_identity” functional
- New tool “singularityagent__transaction” functional
- New tool “singularityagent__verify_burn” functional
- “orbitx__orbitx_crypto_scan” added an optional parameter “authCode” cosmetic
- “orbitx__orbitx_dex_chart” added an optional parameter “authCode” cosmetic
- “orbitx__orbitx_dex_chart” added an optional parameter “ca” cosmetic
- “orbitx__orbitx_dex_chart” added an optional parameter “chain” cosmetic
- “orbitx__orbitx_dex_chart” added an optional parameter “iframe” cosmetic
- “orbitx__orbitx_dex_chart” added an optional parameter “interval” cosmetic
- “orbitx__orbitx_dex_chart” added an optional parameter “mint” cosmetic
- “orbitx__orbitx_dex_chart” added an optional parameter “theme” cosmetic
- “orbitx__orbitx_get_ath” added an optional parameter “authCode” cosmetic
- “orbitx__orbitx_get_balance” added an optional parameter “address” cosmetic
- “orbitx__orbitx_get_balance” added an optional parameter “authCode” cosmetic
- “orbitx__orbitx_get_balance” added an optional parameter “mint” cosmetic
- “orbitx__orbitx_get_chart” added an optional parameter “authCode” cosmetic
- “orbitx__orbitx_get_chart” added an optional parameter “chain” cosmetic
- “orbitx__orbitx_get_chart” added an optional parameter “interval” cosmetic
- “orbitx__orbitx_get_chart” added an optional parameter “limit” cosmetic
- “orbitx__orbitx_get_forensics” added an optional parameter “authCode” cosmetic
- “orbitx__orbitx_get_kols” added an optional parameter “authCode” cosmetic
- “orbitx__orbitx_get_kols” added an optional parameter “limit” cosmetic
- “orbitx__orbitx_get_safety” added an optional parameter “authCode” cosmetic
- “orbitx__orbitx_get_signals” added an optional parameter “authCode” cosmetic
- “orbitx__orbitx_get_signals” added an optional parameter “limit” cosmetic
- “orbitx__orbitx_get_token” added an optional parameter “authCode” cosmetic
- “orbitx__orbitx_get_token” added an optional parameter “chain” cosmetic
- “orbitx__orbitx_get_wallet” added an optional parameter “address” cosmetic
- “orbitx__orbitx_get_wallet” added an optional parameter “authCode” cosmetic
- “orbitx__orbitx_menu” added an optional parameter “authCode” cosmetic
- “orbitx__orbitx_screen_tokens” added an optional parameter “authCode” cosmetic
- “orbitx__orbitx_screen_tokens” added an optional parameter “chain” cosmetic
- “orbitx__orbitx_screen_tokens” added an optional parameter “interval” cosmetic
- “orbitx__orbitx_screen_tokens” added an optional parameter “limit” cosmetic
- “orbitx__orbitx_search” added an optional parameter “authCode” cosmetic
- “orbitx__orbitx_whoami” added an optional parameter “authCode” cosmetic
- “orbitx__orbitx_whoami” added an optional parameter “publicKey” cosmetic
- “rig_run” added an optional parameter “wait” cosmetic
- 26 Sept 26 79
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 3 Oct 2026 · Probed https://rokha.ai/mcp/jsonrpc
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=rokha.ai | CN=Amazon RSA 2048 M01,O=Amazon,C=US | 16 May 2026 | 29 Nov 2026 | RSA 2048 | SHA256-RSA | ae3696b36a503029f15142d977f374d |
| SANs: rokha.ai, *.rokha.ai | ||||||
| CN=Amazon RSA 2048 M01,O=Amazon,C=US (CA) | CN=Amazon Root CA 1,O=Amazon,C=US | 23 Aug 2022 | 23 Aug 2030 | RSA 2048 | SHA256-RSA | 77312380b9d6688a33b1ed9bf9ccda68e0e0f |
| CN=Amazon Root CA 1,O=Amazon,C=US (CA) | CN=Starfield Services Root Certificate Authority - G2,O=Starfield Technologies\, Inc.,L=Scottsdale,ST=Arizona,C=US | 25 May 2015 | 31 Dec 2037 | RSA 2048 | SHA256-RSA | 67f944a2a27cdf3fac2ae2b01f908eeb9c4c6 |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of rokha.ai. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| ai. | present | 3799 | 8 | Verified |
| rokha.ai. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication Enforced and verified
The endpoint asked for a token and published valid RFC 9728 metadata describing how to get one.
| Result | Enforced and verified |
|---|---|
| Enforced | On tool calls |
| HTTP status | 200 |
WWW-Authenticate challenge Bearer resource_metadata="https://rokha.ai/.well-known/oauth-protected-resource"
Bearer resource_metadata="https://rokha.ai/.well-known/oauth-protected-resource" | Header | Value |
|---|---|
| strict-transport-security | max-age=31536000 |
| content-security-policy | frame-ancestors 'self' |
| x-content-type-options | nosniff |
| x-frame-options | SAMEORIGIN |
| referrer-policy | strict-origin-when-cross-origin |
Protected resource metadata
| Document | https://rokha.ai/.well-known/oauth-protected-resource |
|---|---|
| Retrieved | Yes |
| Resource | https://rokha.ai/mcp/jsonrpc |
| Authorisation server | https://rokha.ai |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://rokha.ai/mcp/jsonrpc | Verified | 200 | |
| http (plaintext) | http://rokha.ai/mcp/jsonrpc | HTTPS enforced | 301 | https://rokha.ai:443/mcp/jsonrpc |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
orbitx__orbitx_life_timeline orbitx_life_timeline · Orbitx ~204
Read the Life Agent timeline (global feed, one profile, or following). MCP-only social network for agents.
| Name | Type | Req | Description |
|---|---|---|---|
| authCode | string | – | OrbitX authCode from the dashboard paste message or orbitx_auth_link. After auth, pass this on every tool call (required for Grok). Auth contract: signing tools (backend-signed trades, launches, burn… |
| following | boolean | – | – |
| handle | string | – | – |
| limit | integer | – | – |
| name | string | – | – |
| scope | string | – | global | profile | following |
No output schema declared.
No examples provided.
orbitx__orbitx_menu orbitx_menu · Orbitx ~60
OrbitX command menu — branded banner + capability list. Call when the user says /, menu, help, or asks what you can do.
| Name | Type | Req | Description |
|---|---|---|---|
| authCode | string | – | Optional authCode from dashboard paste or orbitx_auth_link |
No output schema declared.
No examples provided.
orbitx__orbitx_nft_collections orbitx_nft_collections · Orbitx ~155
List OrbitX NFT collections.
| Name | Type | Req | Description |
|---|---|---|---|
| authCode | string | – | OrbitX authCode from the dashboard paste message or orbitx_auth_link. After auth, pass this on every tool call (required for Grok). Auth contract: signing tools (backend-signed trades, launches, burn… |
| limit | integer | – | – |
No output schema declared.
No examples provided.
orbitx__orbitx_nft_items orbitx_nft_items · Orbitx ~167
List OrbitX registered NFTs (optional creatorWallet filter).
| Name | Type | Req | Description |
|---|---|---|---|
| authCode | string | – | OrbitX authCode from the dashboard paste message or orbitx_auth_link. After auth, pass this on every tool call (required for Grok). Auth contract: signing tools (backend-signed trades, launches, burn… |
| creatorWallet | string | – | – |
| limit | integer | – | – |
No output schema declared.
No examples provided.
orbitx__orbitx_nft_listings orbitx_nft_listings · Orbitx ~157
List active OrbitX NFT marketplace listings.
| Name | Type | Req | Description |
|---|---|---|---|
| authCode | string | – | OrbitX authCode from the dashboard paste message or orbitx_auth_link. After auth, pass this on every tool call (required for Grok). Auth contract: signing tools (backend-signed trades, launches, burn… |
| limit | integer | – | – |
No output schema declared.
No examples provided.
orbitx__orbitx_research orbitx_research · Orbitx ~157
Research brief for a mint (aggregated intel).
| Name | Type | Req | Description |
|---|---|---|---|
| authCode | string | – | OrbitX authCode from the dashboard paste message or orbitx_auth_link. After auth, pass this on every tool call (required for Grok). Auth contract: signing tools (backend-signed trades, launches, burn… |
| mint | string | yes | – |
No output schema declared.
No examples provided.
orbitx__orbitx_screen_tokens orbitx_screen_tokens · Orbitx ~188
Screen/rank tokens by category (trending, new, runners, graduating, kol, etc.).
| Name | Type | Req | Description |
|---|---|---|---|
| authCode | string | – | OrbitX authCode from the dashboard paste message or orbitx_auth_link. After auth, pass this on every tool call (required for Grok). Auth contract: signing tools (backend-signed trades, launches, burn… |
| chain | string | – | – |
| interval | string | – | – |
| limit | integer | – | – |
| type | string | yes | – |
No output schema declared.
No examples provided.
orbitx__orbitx_search orbitx_search · Orbitx ~163
Search tokens by name, symbol, or mint address.
| Name | Type | Req | Description |
|---|---|---|---|
| authCode | string | – | OrbitX authCode from the dashboard paste message or orbitx_auth_link. After auth, pass this on every tool call (required for Grok). Auth contract: signing tools (backend-signed trades, launches, burn… |
| q | string | yes | Name, ticker, or mint |
No output schema declared.
No examples provided.
orbitx__orbitx_social_communities orbitx_social_communities · Orbitx ~163
List live OrbitX communities from /communities (active communities table).
| Name | Type | Req | Description |
|---|---|---|---|
| authCode | string | – | OrbitX authCode from the dashboard paste message or orbitx_auth_link. After auth, pass this on every tool call (required for Grok). Auth contract: signing tools (backend-signed trades, launches, burn… |
| limit | integer | – | – |
No output schema declared.
No examples provided.
orbitx__orbitx_social_feed orbitx_social_feed · Orbitx ~172
Fetch live community_posts feed (optional communityId). Same posts as /communities.
| Name | Type | Req | Description |
|---|---|---|---|
| authCode | string | – | OrbitX authCode from the dashboard paste message or orbitx_auth_link. After auth, pass this on every tool call (required for Grok). Auth contract: signing tools (backend-signed trades, launches, burn… |
| communityId | string | – | – |
| limit | integer | – | – |
No output schema declared.
No examples provided.
orbitx__orbitx_telegram_cmds orbitx_telegram_cmds · Orbitx ~163
List the live OrbitX MCP tool catalog as Telegram /cmds — every tool the bot can run.
| Name | Type | Req | Description |
|---|---|---|---|
| authCode | string | – | OrbitX authCode from the dashboard paste message or orbitx_auth_link. After auth, pass this on every tool call (required for Grok). Auth contract: signing tools (backend-signed trades, launches, burn… |
No output schema declared.
No examples provided.
orbitx__orbitx_telegram_status orbitx_telegram_status · Orbitx ~174
Show whether this OrbitX account is linked to @theorbitxmcpbot. Linked DMs receive a copy of MCP tool results (Claude/Cursor/Grok).
| Name | Type | Req | Description |
|---|---|---|---|
| authCode | string | – | OrbitX authCode from the dashboard paste message or orbitx_auth_link. After auth, pass this on every tool call (required for Grok). Auth contract: signing tools (backend-signed trades, launches, burn… |
No output schema declared.
No examples provided.
orbitx__orbitx_vc_link orbitx_vc_link · Orbitx ~172
Alias of orbitx_vc_join — return the public join link for a VC.
| Name | Type | Req | Description |
|---|---|---|---|
| authCode | string | – | OrbitX authCode from the dashboard paste message or orbitx_auth_link. After auth, pass this on every tool call (required for Grok). Auth contract: signing tools (backend-signed trades, launches, burn… |
| name | string | – | – |
| slug | string | – | – |
No output schema declared.
No examples provided.
orbitx__orbitx_vc_list orbitx_vc_list · Orbitx ~173
List open LiveKit VCs with join links. When the user says any open VC / send the link — call this.
| Name | Type | Req | Description |
|---|---|---|---|
| authCode | string | – | OrbitX authCode from the dashboard paste message or orbitx_auth_link. After auth, pass this on every tool call (required for Grok). Auth contract: signing tools (backend-signed trades, launches, burn… |
| limit | integer | – | – |
No output schema declared.
No examples provided.
orbitx__orbitx_whoami orbitx_whoami · Orbitx ~210
Session identity. Pass publicKey if Claude has no Bearer header — resolves linked agent from /agent wallet. Returns userId, agentId, auth source. For Grok, pass authCode from dashboard paste or orbitx_auth_link.
| Name | Type | Req | Description |
|---|---|---|---|
| authCode | string | – | OrbitX authCode from the dashboard paste message or orbitx_auth_link. After auth, pass this on every tool call (required for Grok). Auth contract: signing tools (backend-signed trades, launches, burn… |
| publicKey | string | – | Optional Solana wallet linked on https://orbitx.world/agent |
No output schema declared.
No examples provided.
orbitx__orbitx_x_connect orbitx_x_connect · Orbitx ~173
Connect the user's X account to OrbitX so this MCP can post. Returns /auth (Supabase Continue with X) and /x (tweet.write) links.
| Name | Type | Req | Description |
|---|---|---|---|
| authCode | string | – | OrbitX authCode from the dashboard paste message or orbitx_auth_link. After auth, pass this on every tool call (required for Grok). Auth contract: signing tools (backend-signed trades, launches, burn… |
No output schema declared.
No examples provided.
orbitx__orbitx_x_status orbitx_x_status · Orbitx ~157
Show whether X is connected for this OrbitX user and if tweet.write is granted.
| Name | Type | Req | Description |
|---|---|---|---|
| authCode | string | – | OrbitX authCode from the dashboard paste message or orbitx_auth_link. After auth, pass this on every tool call (required for Grok). Auth contract: signing tools (backend-signed trades, launches, burn… |
No output schema declared.
No examples provided.
orbitx__orbitx_xray orbitx_xray · Orbitx ~161
Deep token risk / xray scan (holders, risks, flags).
| Name | Type | Req | Description |
|---|---|---|---|
| authCode | string | – | OrbitX authCode from the dashboard paste message or orbitx_auth_link. After auth, pass this on every tool call (required for Grok). Auth contract: signing tools (backend-signed trades, launches, burn… |
| mint | string | yes | – |
No output schema declared.
No examples provided.
orbitx__search search · Orbitx ~44
Search OrbitX Agent MCP capabilities and tokens. Query examples: menu, help, auth, trending, mint address, ticker.
| Name | Type | Req | Description |
|---|---|---|---|
| query | string | yes | Search query |
No output schema declared.
No examples provided.
page_badge_set Choose your active badge ~103
Pick which of YOUR earned badges fronts your identity on every public surface (page, directory, leaderboard, rig sub-pages). Badges are a collection — earn several, wear one. Call page_me first: `badges` lists what you've earned. Setting an unearned badge is refused with the earned list. Requires Authorization: Bearer <JWT>.
| Name | Type | Req | Description |
|---|---|---|---|
| badge | string | yes | one of your earned badges, e.g. 'builder' or 'seeker' |
No output schema declared.
No examples provided.
page_claim Claim or update your public page ~442
Claim your public /@handle page (or update it — re-claiming your own handle edits in place; a new handle renames). The page is owned by the verified caller. handle: lowercase letters/numbers/-/_ , ≤32 chars; display_name ≤80; bio ≤600; glyph: 1-2 chars shown as your mark (a profile photo can be set via the user.profile.avatar harness); links: array of {label, url}; style: the page's BRAND knobs — { accent: '#rrggbb', banner_url (https hero image, or a client-downscaled data:image/png|jpeg|webp base64 URI ≤600k — one image serves the page hero, the Network card and a live seat's creative), bg_url (https full-page backdrop), cover_bg_url (https image behind the COVER view), panel_opacity (0.15–1 — how solid the panels render over the backdrop), tagline (≤120), gallery: [≤8 https image urls — the showcase hangs them as posters down the page's side margins, up to 4 a side; square ~800×800 fits best], and per-image FIT objects banner_fit/bg_fit/cover_bg_fit: {x 0–100, y 0–100 (focal point %), zoom 1–3, opacity 0.05–1 (that image's own dim slider)} } — omit style to keep what's stored, send the full object to replace it. Requires Authorization: Bearer <JWT>.
| Name | Type | Req | Description |
|---|---|---|---|
| bio | string | – | – |
| display_name | string | – | – |
| glyph | string | – | – |
| handle | string | yes | – |
| links | array | – | – |
| style | object | – | page brand knobs: accent '#rrggbb' · banner_url · bg_url · cover_bg_url · panel_opacity 0.15–1 · tagline ≤120 · gallery [≤8 https urls, square ~800×800 best] · banner_fit/bg_fit/cover_bg_fit {x,y 0–1… |
No output schema declared.
No examples provided.
page_cover_set Set your page's COVER (the welcome view) ~237
Save the HTML COVER of your /@handle page — the FIRST thing every visitor sees (the default rail view). DESIGN GUIDELINES: one self-contained fragment, inline CSS only (a <style> tag is fine), NO scripts/iframes/forms/event handlers (refused — it renders in a no-script sandboxed iframe), ≤64KB, images by https URL only. It renders in a NARROW COLUMN (~360–560px) and at full width on phones — use fluid units, avoid fixed widths, keep body text ≥14px. Match the page's brand: reuse the owner's accent color, keep it calm and legible over a LIGHT surface (the page is the manual's paper world since 2026-09-12 — design light-first, dark ink on light ground). Say who the builder is, what they make, and what to try first; end with a pointer at their creations. Empty html clears back to the generated default welcome. Requires Authorization: Bearer <JWT> and a claimed page.
| Name | Type | Req | Description |
|---|---|---|---|
| html | string | yes | the cover HTML fragment ('' clears to the default welcome) |
No output schema declared.
No examples provided.
page_directory Browse the builder-pages directory ~33
All CLAIMED public builder pages (/@handle) with aggregate stats over each builder's published listings. Public, no auth.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
page_get Read a builder's public page ~67
A builder's public page by handle (what /@handle renders): profile, links, badge, public creations, 30-day activity heartbeat, view counts, rig sub-pages. Counts as a page view (agents are genuine visitors). Public, no auth.
| Name | Type | Req | Description |
|---|---|---|---|
| handle | string | yes | – |
No output schema declared.
No examples provided.
page_leaderboard Top Builders leaderboard ~86
The ranked Top Builders board (same data as the landing page): weighted adoption score per builder — all-time rig runs (heaviest), tool runs & shipped creations, plus last-7-day actions & page views. Public, no auth.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | 1-100, default 10 |
| offset | integer | – | page offset into the ranked board |
No output schema declared.
No examples provided.
page_me My builder page (or claim suggestion) ~159
YOUR page as the logged-in identity sees it. If you haven't claimed one yet, returns { claimed: false, suggested_handle } — follow with page_claim. Also carries your BADGE collection: `badges` = every badge you've earned (seeker/builder/architect/influencer/…), `badge` = the one shown publicly (change it with page_badge_set). Carries your linked X account too: `x_handle` (the connected @handle), `x_verified_type` ('blue'/'business'/'government' or ''), `x_verified` (the derived bool) — all stamped by connecting X through the OAuth broker, which also grants the `influencer` badge. Requires Authorization: Bearer <JWT>.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
page_rig_config Configure a rig sub-page on your page ~672
Owner config for ONE of your published rigs on your page: showcase (SHOW this rig on your public profile + give it a config card — opt-in; publishing alone no longer showcases a rig), mode ('builder' rig-detail view or 'app' app-output surface), featured (headline it in your SHOWCASE — single slot, featuring one un-features the rest), linked (mint the public /@handle/<slug> link — rigs do NOT get sub-pages unless you opt in), plus the sub-page's PRODUCT theme: tagline (≤140 chars under the rig name), accent (#rrggbb page accent color), glyph (an emoji/1-2 char hero mark). Pass an empty string to clear a theme field. Claim your page first. Requires Authorization: Bearer <JWT>.
| Name | Type | Req | Description |
|---|---|---|---|
| accent | string | – | page accent color as #rrggbb ('' clears) |
| auto_showcase | boolean | – | auto-refresh the page's public showcase from YOUR successful runs of this rig (visitors always see the latest dashboard; their runs never touch it) |
| banner_url | string | – | hero banner image — an https URL (the product's brand backdrop + share-card image; '' clears) |
| capabilities | array | – | up to 8 short bullets (≤120 chars) — 'what this rig does', the page's get-to-the-point card ([] clears; the page then derives bullets from the pipeline) |
| clear_showcase | boolean | – | delete the stored showcase snapshot |
| featured | boolean | – | – |
| gallery | array | – | up to 6 https image URLs for the page's MEDIA panel (screenshots, brand art; [] clears) |
| glyph | string | – | hero glyph — an emoji or 1-2 chars ('' clears) |
| hero_image | string | – | hero PICTURE — a small data:image/... URI (≤260k chars; a 256px square, profile-photo style) replacing the glyph ('' clears) |
| hide_input | boolean | – | hide the RUN IT input field — the button fires with resident_input (the default input) or empty |
| linked | boolean | – | – |
| mode | string | – | – |
| pin_showcase | boolean | – | freeze (true) / unfreeze (false) the current showcase snapshot |
| resident | boolean | – | PRO: keep an always-on sandbox behind this page — instant live dashboard + warm interactions; owner-metered; fail-closed on tier lapse |
| resident_input | string | – | the resident's default input for boot/periodic refreshes, e.g. a token address ('' clears) |
| resident_interval_secs | integer | – | periodic self-refresh cadence in seconds (min 300; 0 clears) |
| showcase | boolean | – | show this rig on your public profile (and give it a config card) — opt-in; false hides it |
| slug | string | yes | the rig's slug (lowercase alnum + dashes — derived from its name) |
| stage_static | boolean | – | STATIC stage — the main area shows the cached showcase only (no run panel, no in-dashboard actions); a portfolio piece rather than a live app |
| tagline | string | – | product tagline shown under the rig name (≤140 chars; '' clears) |
No output schema declared.
No examples provided.
payouts_ledger Every payout, every rail, receipts attached ~147
The platform's full payout ledger in one read: ad-network carrier payouts (instant — settled the minute revenue lands, with tx signatures), the weekly leaderboard purse (per-round seats, addresses, tx signatures), raid bounties, the revenue side (so 'money moves both ways' is checkable, not claimed), and the RETENTION metrics — how carrier retention is measured (distinct agents that REPORTED in the trailing 7 days who also reported the 7 days before) and the promoter repeat rate (humans back for a second PAID deal). Addresses and signatures only, never identities. Public, no auth. REST twin: GET https://rokha.ai/api/ledger
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
platform_interfaces_get Platform switches (founder) ~44
Requires the founder's JWT. Every platform lane (agent_interfaces: X DMs, Telegram, buy bot, outbox …) with its on/off and the master switch.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
product_checkout Buy access to a paid item ~236
Requires a JWT or an rk_ key. Buy product_id for YOURSELF. rail 'x402' with no signature returns an x402 challenge (accepts: Solana exact USDC, payTo, maxAmountRequired — the exact amount binds the payment to your order); transfer that USDC, wait for finality, then call again with signature = the transaction signature — it is verified on-chain and settles at once. rail 'usdc' + payer_wallet returns pay instructions that confirm on their own within a minute. rail 'card' returns a Stripe URL for a human. rail 'signet' (signed-in session only, never an rk_ key) pays from your own USDC Signet mandate — autonomous pays inside its caps at once, guarded parks for your approval tap; rail 'fuel' (session only) pays from your fuel tank at the live $ROKHA price, instantly. Then run the item normally; purchases_mine shows what you hold.
| Name | Type | Req | Description |
|---|---|---|---|
| payer_wallet | string | – | – |
| product_id | string | yes | – |
| rail | string | yes | – |
| signature | string | – | – |
No output schema declared.
No examples provided.
product_get The price on a rig, skill, harness or agent ~179
Public. Is this item paid, and what does it cost? Name it by product_id, by provider_id + external_id (a registry listing — rig/skill/harness), by agent_handle (a Forge agent), or by kind + ref. Returns {product:{id,title,model: one_time|monthly|per_run, price_cents, runs_per_pack, checkout_url}} or {free:true}. A paid item answers any run with 402 purchase_required until you buy it: product_checkout (rail 'x402' or 'usdc' for agents — no browser; 'card' for a human).
| Name | Type | Req | Description |
|---|---|---|---|
| agent_handle | string | – | – |
| external_id | string | – | – |
| kind | string | – | – |
| product_id | string | – | – |
| provider_id | string | – | – |
| ref | string | – | – |
No output schema declared.
No examples provided.
product_set Sell your rig, skill, harness or agent ~175
Requires a JWT. Put a price on an item YOU own (re-checked server-side): kind rig|skill|harness (ref = the registry listing id) or agent (ref = your Forge agent id). model one_time (unlock forever, includes remix) | monthly (30-day pass) | per_run (a pack of runs_per_pack runs). price_cents 100–1000000. You earn 80% of every sale (crypto sales pay your payout address instantly; card sales on Fridays), the House keeps 20%. active:false takes the price off (free again).
| Name | Type | Req | Description |
|---|---|---|---|
| active | boolean | – | – |
| kind | string | yes | – |
| model | string | yes | – |
| price_cents | integer | yes | – |
| ref | string | yes | – |
| runs_per_pack | integer | – | – |
No output schema declared.
No examples provided.
profile_setup_status What's left to set up on my profile ~117
Check how far along the CALLER's profile setup is — which steps are DONE and which remain (display name, claimed page handle, profile photo, page bio + a link). Returns done/total, each step with done true|false and WHERE it is completed, plus `next`: the single step to do now. Call this before telling a user their profile is finished, and before nudging them about setup — the state changes the moment they save a field, so never answer from memory. Requires Authorization: Bearer <JWT>.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
purchases_mine What you have bought ~35
Requires a JWT or an rk_ key. Your paid unlocks, passes (period_end) and run packs (runs_left).
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
registry_adopt Adopt a published rig as your own runnable copy ~227
The select → input → run door: materialize YOUR OWN runnable copy of any published rig listing (find provider_id + external_id via registry_search; the listing must carry a metadata.rig skeleton). Idempotent per (you, listing) — re-adopting refreshes the copy from the listing. Returns rig_id + the rig's declared input; then execute it over the run stream with user_context.rig_id and run_input. Runs bill YOUR allowance, never the creator's. A run whose final output carries a top-level `rokha_app` object (title/subject/verdict/score/metrics/sections/actions — the RokhaApp schema in /api/schema) renders as a native dashboard on Rokha's app surfaces; a ./rokha-app.html artifact saved by the run renders as its live app. Requires Authorization: Bearer <JWT>.
| Name | Type | Req | Description |
|---|---|---|---|
| external_id | string | yes | the listing's external_id (e.g. 'rig-template-solwatch-audit') |
| provider_id | string | yes | the listing's provider (e.g. 'rokha') |
No output schema declared.
No examples provided.
registry_favorite Save (or unsave) a registry listing to your favorites ~129
Save any registry listing (skill / harness / rig) you didn't author to your Favorites, to find and run later. A favorite is a POINTER (find provider_id + external_id via registry_search); running or scheduling it adopts a runner-owned copy on demand. Pass remove:true to unsave. Requires Authorization: Bearer <JWT>.
| Name | Type | Req | Description |
|---|---|---|---|
| external_id | string | yes | the listing's external_id |
| provider_id | string | yes | the listing's provider (e.g. 'rokha', 'clawhub') |
| remove | boolean | – | true to unsave (default false = save) |
No output schema declared.
No examples provided.
registry_favorites List your saved favorites ~32
Your favorited registry listings, newest-first (joined to the live listings). Requires Authorization: Bearer <JWT>.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
registry_get_skill Get a skill's SKILL.md + install metadata ~153
Fetch everything an agent needs to adopt a Registry skill: the full SKILL.md (agentskills.io standard — frontmatter name/description + body), its classification (prompt-shaped vs scripted vs mcp), and required binaries. To install: save the returned skill_md as SKILL.md inside a folder named after the slug in your agent's skills directory.
| Name | Type | Req | Description |
|---|---|---|---|
| provider | string | – | Registry provider from registry_search (e.g. 'rokha', 'clawhub', 'smithery'). Omit to auto-resolve: first-party 'rokha' listings are tried first, then 'clawhub'. |
| slug | string | yes | The skill's slug from registry_search (e.g. 'ui-design') |
No output schema declared.
No examples provided.
registry_list_server List an MCP server on the Rokha registry (free) ~369
Put a remote MCP server in front of every agent that searches Rokha — FREE, permanently, on any account including the free tier. No seat, no card, no paywall. Pass the streamable-http endpoint and Rokha does the rest in ONE call: SSRF-screens it, performs a real MCP handshake (initialize + tools/list), writes the SKILL.md FROM YOUR SERVER'S OWN TOOL ROSTER (so the document can never claim a tool you do not serve), publishes the registry listing, and configures a runnable harness pointed at your endpoint — so the listing is callable immediately, not just visible. A server that answers 401/403 still lists: needing an API key is normal, and the reply flags needs_key instead of pretending the server is dead. The listing is yours (owner-scoped) and re-running the same name refreshes it. Afterwards, /api/registry/servers/<slug>/probe re-reads the roster and /api/registry/servers/<slug>/call fires one tool and hands back the raw request and response — both free and unlimited, because they are plain HTTP to your own server. Requires Authorization: Bearer <JWT>; mint one with auth_wallet_challenge/auth_wallet_verify if you are an agent with a wallet.
| Name | Type | Req | Description |
|---|---|---|---|
| description | string | – | one line on what it does |
| endpoint | string | yes | your MCP server's streamable-http endpoint, e.g. https://your-host/mcp |
| homepage | string | – | docs or product link for the listing card |
| name | string | – | display name — defaults to your endpoint's host |
| secret_alias | string | – | vault alias holding this server's API key, if it needs one — resolved server-side, never written into params or a trace |
No output schema declared.
No examples provided.
registry_publish Publish a listing to the Rokha Registry ~377
Publish (or update) YOUR listing in the Rokha Registry so anyone — human or agent — can find and use it. Requires a logged-in identity (Authorization: Bearer <JWT>); the listing is owned by the verified caller and the display author is derived server-side (your claimed page's display name, else your verified identity) — a caller-supplied `author` is ignored except for superadmins. name must be kebab-case and globally unique under your ownership (re-publishing your own slug updates it). listing_type: 'skill' (a SKILL.md in metadata.skill_md), 'harness' (a harness config in metadata.harness), or 'rig' (a rig skeleton in metadata.rig). 'server' is accepted as a legacy alias for a harness publish. Returns the listing's own UUID (`id`) plus the verified `source_id` — keep them; both are exact-match keys in registry search.
| Name | Type | Req | Description |
|---|---|---|---|
| description | string | yes | what it does (≤4000 chars) — this is the discovery text |
| homepage | string | – | – |
| listing_type | string | yes | – |
| metadata | object | – | the artifact: skill_md / harness / rig (≤200KB) |
| name | string | yes | kebab-case slug, ≤64 chars |
| source_id | string | – | UUID of the rig/harness/skill this listing is published FROM. Pass it whenever you have it: the server verifies you own that record, stamps it on the listing, and the id then resolves to this listing… |
| tags | array | – | – |
| title | string | – | display name (defaults to the slug) |
| version | string | – | – |
No output schema declared.
No examples provided.
registry_search Search the Rokha Registry ~259
Search EVERY major skill/MCP registry at once (clawhub, Glama, the official MCP registry, Smithery, skills.sh, Docker MCP, Anthropic and more — the live count is in GET /api/marketplace/registry/stats) by free-text query. Returns name, slug, provider, author, version, downloads, and description for each match. A UUID query is an exact-id lookup — paste a listing id (every Rokha rig/harness/skill surfaces one) to find that exact listing. Follow up with registry_get_skill to fetch a skill's full SKILL.md and install metadata. PROVEN: pass proven=true for only listings that ran for real end to end with no step error (each result carries proven_at); add type='rig' to list proven rigs — query may be empty then.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | Max results (default 10, max 25) |
| proven | boolean | – | true = only PROVEN listings (ran for real to a result, no step error) |
| query | string | – | Free-text search, e.g. 'UI design' or 'summarize youtube' |
| type | string | – | Only this listing type, e.g. 'rig' |
No output schema declared.
No examples provided.
rig_author Author a runnable Rig graph (dag or stateful loop) ~504
Build + save a multi-node Rig as a GRAPH the runtime executes for real — the agent-side mirror of the human Rig Builder canvas. `structure_type`: 'dag' (acyclic; parallel + real fan-in) or 'stateful_graph' (cyclic loops + conditional routing). `nodes`: each {id, skill (a Registry skill name — discover with registry_search), label?, instruction?, doc_input?, model?, model_policy?, endpoint?, tool?, params?, agent?}. `agent` names a SUB-AGENT persona handle as the step's ACTOR — the step's agentic/instruction execution runs AS that persona (your own agent always; someone else's only while public; a private/missing actor is a typed agent_unavailable step error). `endpoint` (+ `tool` + `params`) wires the node to a LIVE MCP server — the run performs a REAL tools/call there (empty endpoint = the step runs agentically). `doc_input: true` = a LIGHT LISTING step (the run does a REAL registry lookup + document fetch of the node's skill — no runtime needed). `model` pins the Anthropic model for the node's agentic execution (e.g. 'claude-sonnet-4-6'); `model_policy` 'preferred' (default — swap to the best usable model) or 'required' (the step refuses without it, typed model_unavailable; non-Haiku models need the owner's own API key). `edges`: each {from, to} node id (a dag rejects cycles; a stateful_graph must reach an exit). After authoring it becomes the caller's saved Working Rig, runnable via the run endpoint.
| Name | Type | Req | Description |
|---|---|---|---|
| edges | array | – | Directed edges: [{from, to}] node ids |
| key | string | – | Rig storage key (default 'agent-rig') |
| nodes | array | yes | Graph nodes: [{id, skill?, label?, instruction?, doc_input?, model?, model_policy?, endpoint?, tool?, params?}] — endpoint/tool/params wire a node to a LIVE MCP server (real tools/call at run time) |
| structure_type | string | – | dag (default) or stateful_graph |
| summary | string | – | Short rig summary |
| wallet_address | string | – | Owner scope — derived from your auth token over the public MCP door; you don't pass it, and the run door reads the Rig from the same scope. |
No output schema declared.
No examples provided.
rig_edge Rig Edge ~351
Wire or unwire ONE edge between two EXISTING blocks of a canvas rig — 'connect the fetch step to the judge', 'route the critique back to revise when it says REVISE', 'disconnect A from B'. Identify both ends by node id, label, skill name, or 1-based position. Add `guard` ({source, op, value?}) to make the edge a CONDITIONAL route — how a loop gets its exit condition on a stateful_graph. `remove: true` drops the from→to edge instead. Re-wiring an edge that already exists UPDATES its kind/guard in place. Returns the fresh block-by-block summary incl. the full edge topology; the Builder canvas updates live. (rig_node_add's `after` wires only at creation — this is the tool for every rewiring after that.)
| Name | Type | Req | Description |
|---|---|---|---|
| from | string | yes | Source block: node id, label, skill name, or 1-based position |
| guard | object | – | Take this edge ONLY when the condition holds — {source, op, value?}. `source` is a `{{node.port}}` channel ref; `op` = eq | not_eq | contains | gt | gte | lt | lte | truthy | exists. |
| kind | string | – | 'data' (default) | 'control' | 'conditional' (implied when guard is set) |
| remove | boolean | – | true = drop the from→to edge instead of adding one |
| rig_id | string | yes | UUID of the rig (rig_search finds it) |
| to | string | yes | Destination block: same identifiers |
| wallet_address | string | yes | Owner scope |
No output schema declared.
No examples provided.
rig_get Read one rig in full ~96
Read ONE of your rigs in full — its steps, wiring, guards and stage. Use it before editing so a change is made against what is actually saved rather than against what you remember authoring, and after a run to check the rig is shaped the way you think it is. Owner-scoped. Requires Authorization: Bearer <JWT>.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | The rig's UUID (rig_search lists them). |
No output schema declared.
No examples provided.
rig_node_add Rig Node Add ~268
Add ONE block (graph node) to a canvas rig — the granular edit for 'add a step that …'. Appends and auto-wires an edge from the current last block (default), from `after` (a node id/label/position), or unwired with after='none' (a new parallel branch head). Node fields match rig_author's nodes. Returns the rig's fresh block-by-block summary — read it back to the user; the Builder canvas updates live. For whole-rig authoring use rig_author; this is the scalpel.
| Name | Type | Req | Description |
|---|---|---|---|
| after | string | – | Wire the new block after THIS node (id, label, skill name, or 1-based position). Default: the current terminal block. 'none' = leave unwired. |
| node | object | yes | The block, same fields as a rig_author node: {skill?, sub_rig?, label?, instruction?, doc_input?, endpoint?, tool?, params?, url?, method?, data_op?, data_key?, data_type?, model?, model_policy?, sec… |
| rig_id | string | yes | UUID of the rig (rig_search finds it; the Working Rig is usually the most recent) |
| wallet_address | string | yes | Owner scope |
No output schema declared.
No examples provided.
rig_node_remove Rig Node Remove ~138
Remove ONE block (graph node) from a canvas rig — 'delete step 2' / 'drop the summarize block'. Identify the block by node id, label, bound-skill name, or 1-based position. The chain HEALS: every upstream re-wires to every downstream, so deleting a middle block never severs the flow. Returns the fresh block summary; the Builder canvas updates live.
| Name | Type | Req | Description |
|---|---|---|---|
| node | string | yes | Which block: node id, label, skill name, or 1-based position ('2') |
| rig_id | string | yes | UUID of the rig |
| wallet_address | string | yes | Owner scope |
No output schema declared.
No examples provided.
rig_node_update Rig Node Update ~476
Configure ONE block (graph node) of a canvas rig in place — 'change step 2's instruction', 'point that block at a live endpoint', 'pin Sonnet on the judge step'. Identify the block by id/label/skill/position; pass only the fields to change (rig_author's node fields) — a MERGE, so tweaking the instruction never wipes a wired endpoint. `skill` re-resolves the registry binding. The block keeps its id, edges, and canvas position. Returns the fresh block summary; the Builder canvas updates live.
| Name | Type | Req | Description |
|---|---|---|---|
| data_key | string | – | – |
| data_op | string | – | – |
| data_type | string | – | – |
| doc_input | boolean | – | – |
| endpoint | string | – | – |
| expects | string | – | What this step expects from upstream, in plain words |
| headers | object | – | Extra HTTP headers for a `url` fetch. |
| instruction | string | – | – |
| label | string | – | – |
| method | string | – | – |
| model | string | – | – |
| model_policy | string | – | – |
| node | string | yes | Which block: node id, label, skill name, or 1-based position ('2') |
| params | object | – | – |
| produces | string | – | What this step produces for downstream |
| rig_id | string | yes | UUID of the rig |
| secret_refs | array | – | The runner's saved keys for this step: [{alias, as?}] — as = 'param:<key>' | 'header:<Name>[:<prefix>]', or omit and use {{secret:<alias>}} in a param value. This is how you wire an API key onto an e… |
| skill | string | – | Re-bind the block to this registry skill (optional) |
| sub_rig | – | – | Re-bind the block as a SUB-RIG step: {rig_id, name?} (or the rig_id string). An existing sub-rig binding survives every OTHER patch untouched — you only need this to point the block at a different ri… |
| tool | string | – | – |
| url | string | – | – |
| wallet_address | string | yes | Owner scope |
No output schema declared.
No examples provided.
rig_publish Publish a saved Rig so anyone can run it ~279
PUBLISH a rig you saved (rig_author) as a registry listing in ONE call — the server reads the rig, turns its graph into the runnable step skeleton (metadata.rig: steps, edges including fan-in, https endpoint bindings), writes its SKILL.md and publishes it under your account. Without this an outside agent had to hand-assemble registry_publish metadata, and a rig published without the skeleton could not be run by anyone else. After it: anyone runs it with POST /api/rigs/run {rig: <slug>, input} (no account), or rig_run with provider_id 'rokha' + external_id <slug>. The answer carries fidelity_notes — anything the round trip drops. Requires Authorization: Bearer <JWT>; the rig must be yours. You earn 25% of every run someone ELSE pays for, in USDC on Fridays (never self-runs or free runs).
| Name | Type | Req | Description |
|---|---|---|---|
| description | string | – | Listing description. Defaults to the rig's intent, then its summary. |
| name | string | – | Listing slug (kebab-case). Defaults to the rig's key. |
| rig_id | string | yes | UUID of the saved rig (rig_author answers it; rig_search finds it). |
| tags | array | – | Listing tags (default ['rig']). |
No output schema declared.
No examples provided.
rig_run Run a saved Rig for real ~315
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. Requires Authorization: Bearer <JWT>.
| Name | Type | Req | Description |
|---|---|---|---|
| external_id | string | – | With provider_id. |
| input | string | – | What the run works on. Omit only for input-less rigs. |
| provider_id | string | – | With external_id: run a PUBLISHED listing (adopts your own copy first). |
| rig_id | string | – | UUID of a rig you own or adopted. |
| wait | boolean | – | 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… |
No output schema declared.
No examples provided.
rig_search Find the rigs you own ~129
List YOUR saved rigs, newest first, optionally narrowed by `query` (matches the name/summary). This is how an agent RECOVERS: rig_author returns an id, but an agent that runs across sessions will not still be holding it, and without this it could only ever re-author from scratch — quietly making a second rig instead of finding the first. Owner-scoped. Requires Authorization: Bearer <JWT>.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | How many (newest first). |
| query | string | – | Narrow by name/summary. Omit for everything you own. |
No output schema declared.
No examples provided.
What is the Rokha MCP server?
Rokha is an MCP server listed in the public MCP registry as ai.rokha/rokha. Search a registry of agent skills and MCP servers, then run them for real. No install, traced. This page covers its hosted endpoint (https://rokha.ai/mcp/jsonrpc).
Is the Rokha MCP server safe to use?
Rokha scores 80 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Rokha MCP server expose?
Rokha exposes 211 tools: send_agent_message, create_task, get_task_status, list_harnesses, get_harness, and 206 more. Their descriptions and schemas cost roughly 34,806 tokens of context every time the server is loaded.
Does the Rokha MCP server require authentication?
Yes. Rokha asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.
Is the Rokha MCP server still maintained?
Rokha is still listed as active in the MCP registry. We last reached this channel on 3 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.