Skip to main content
Glama

Create your own agent

agent_create

Requires a JWT (sign in headlessly with auth_wallet_challenge → auth_wallet_verify). Creates a Forge agent you own — the same door and the same checks as the Forge 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 (1 agent free; the Studio lifts it) — at the cap it answers 402 publish_cap. People who chat your agent pay for their own turns. 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

TableJSON Schema
NameRequiredDescriptionDefault
nameYesDisplay name, ≤60 chars.
rigsNo
glyphNoAn emoji or ≤4 characters.
modelNoOptional model id; empty = the platform default.
accentNoA hex colour like #22d3ee.
handleYesIts @handle on rokha.ai — lowercase letters, numbers, - and _.
skillsNo
statusNo
personaNoThe voice and job it answers with, ≤4000 chars. Required to go live.
taglineNoOne line, ≤140 chars — shown on its market card.
toolkitNo
greetingNo
avatar_urlNoAn https image URL.
visibilityNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • 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"
      -}
  2. Changed1 schema field changed
    • 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"
      +}
  3. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false / destructiveHint=false; the description goes well beyond that with validation behavior (reserved names and taken handles refused, models without a key refused), auth requirements, a named error at the publish cap (402 publish_cap), and the allowance/economics model. This is the disclosure an agent needs for a 14-param mutation.

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 prerequisite and creation action are front-loaded, but the body is a dense run-on of parentheticals, and several sentences (80% sale split, referral earnings, 2People who chat your agent pay for their own turns) belong to product_set/payout_wallet_set rather than agent_create. Useful content is present but diluted.

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?

With no output schema, the description still covers prerequisites, validation, defaults, error behavior, and follow-on tools for a 14-parameter tool, which is substantial. The notable gap is what the call returns (agent id/object), which the agent must infer.

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 only 57%, but the description compensates by adding handle constraints (≤32, reserved/taken refused), persona being required to go live, model empty = platform default, visibility defaulting to private, and the status enum values. It also clarifies the rigs {id,name} and skills {name,note} shapes. A few params (greeting, glyph, accent) still get no added meaning.

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?

The description names a specific verb and resource ("Creates a Forge agent you own") and explicitly differentiates from siblings by naming agent_publish, product_set, and payout_wallet_set with their distinct roles. An agent can tell this apart from agents_mine or agents_directory without opening any 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?

It gives a clear prerequisite chain (JWT via auth_wallet_challenge → auth_wallet_verify) and an explicit next-step chain (agent_publish, product_set, payout_wallet_set) that tells the agent where this fits in a workflow. It stops short of an explicit "use this instead of X" exclusion against a look-alike sibling, which keeps it from a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.