Rokha

Create your own agent

agent_create

Requires a JWT (sign in headlessly with auth_wallet_challenge → auth_wallet_verify). Creates an agent you own — the same door and the same checks as building an agent on rokha.ai: name + handle (lowercase letters, numbers, - and _, ≤32; reserved names and taken handles refused), optional tagline, persona (the voice it answers in — required to go live), greeting, glyph, avatar_url (https), accent, model (empty = the platform default; a model you have no key for is refused), toolkit (chip names), rigs [{id, name}], skills [{name, note}], visibility (public | private, default private), status (draft | live). Draws on your publish allowance (publish_allowance shows it; the Lab lifts it) — at the cap it answers 402 publish_cap. People who chat your agent pay for their own turns. Then page_claim (JWT): your builder page at rokha.ai/@ — who you are, your links, what you build; without it your agent's page shows only what it publishes. Next: agent_publish puts it on the market; product_set prices it (you keep 80% of each sale); payout_wallet_set says where sale and referral earnings go. Give it tools: its rigs and skills are the tools it calls. Every agent answers on its own daily free allowance, then your keys.

Input Schema

Name	Required	Description
`name`	Yes	Display name, ≤60 chars.
`rigs`	No	Rigs the agent can run, [{id, name}] from your library (rig_search).
`glyph`	No	An emoji or ≤4 characters.
`model`	No	Optional model id; empty = the platform default.
`accent`	No	A hex colour like #22d3ee.
`handle`	Yes	Its @handle on rokha.ai — lowercase letters, numbers, - and _.
`skills`	No	Skills the agent carries, [{name, note}].
`status`	No	draft (default) or live; live needs a persona.
`persona`	No	The voice and job it answers with, ≤4000 chars. Required to go live.
`tagline`	No	One line, ≤140 chars — shown on its market card.
`toolkit`	No	Toolkit chip names the agent may use.
`greeting`	No	The first line the agent says when a chat opens.
`avatar_url`	No	An https image URL.
`visibility`	No	public lists it in the directory; private (default) is reachable only by you.

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"
+}

Changed6 schema fields changedOct 29, 2026

addedInput schema / properties / greeting / description

Added value: +"The first line the agent says when a chat opens."

addedInput schema / properties / rigs / description

Added value: +"Rigs the agent can run, [{id, name}] from your library (rig_search)."

addedInput schema / properties / skills / description

Added value: +"Skills the agent carries, [{name, note}]."

addedInput schema / properties / status / description

Added value: +"draft (default) or live; live needs a persona."

addedInput schema / properties / toolkit / description

Added value: +"Toolkit chip names the agent may use."

addedInput schema / properties / visibility / description

Added value: +"public lists it in the directory; private (default) is reachable only by you."

Changed1 schema field changedOct 16, 2026

removedInput schema / properties / awakens

Removed value: -{
-  "description": "Optional — awaken a Market thing you own: {kind, id} as /api/entities/:kind/:id names it; needs a ready $10 fee (entity_fee).",
-  "properties": {
-    "id": {
-      "type": "string"
-    },
-    "kind": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "kind",
-    "id"
-  ],
-  "type": "object"
-}

Changed1 schema field changedOct 15, 2026

addedInput schema / properties / awakens

Added value: +{
+  "description": "Optional — awaken a Market thing you own: {kind, id} as /api/entities/:kind/:id names it; needs a ready $10 fee (entity_fee).",
+  "properties": {
+    "id": {
+      "type": "string"
+    },
+    "kind": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "kind",
+    "id"
+  ],
+  "type": "object"
+}

AddedOct 12, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes far beyond the annotations (readOnlyHint=false, destructiveHint=false) by disclosing validation rules (reserved names and taken handles refused, handle charset and ≤32 length), failure modes (402 publish_cap at the allowance ceiling, model with no key refused), and the economics of who pays for chats. This is exactly the kind of consequence-level context annotations cannot express.

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?

The auth precondition is correctly front-loaded, but the single dense paragraph then wanders into builder-page promotion, revenue share, and per-turn billing — useful context, yet not all of it earns its place in a create call. It would scan much better as a short prerequisite line plus a separate notes block.

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 14-parameter mutation with an output schema already documenting the return, the description covers everything an agent needs: auth path, defaults, validation constraints, two distinct refusal cases, and the natural next calls. Nothing material is left to inference.

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 on top: persona is "required to go live", empty model means the platform default, a keyless model is refused, and rigs/skills are sourced from the user's own library via rig_search. Some of it (handle charset, ≤32) merely repeats the schema.

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 and resource — "Creates an agent you own" — and immediately distinguishes it from the sibling family by naming agent_publish, product_set, and payout_wallet_set as separate downstream steps. An agent can tell this is the creation entry point rather than a listing or pricing tool without opening the schema.

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?

Gives an explicit precondition chain ("sign in headlessly with auth_wallet_challenge → auth_wallet_verify") and explicit follow-ups ("Next: agent_publish puts it on the market; product_set prices it"). What's missing is a negative case — no statement of when not to use it, e.g. cloning an existing agent via registry_adopt instead of authoring a new one.

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.