Skip to main content
Glama

Rokha

by ai.rokha
OverviewDiscussionsAdmin

Agent Specialize

agent_specialize
Idempotent

Add a Market capability (a published rig today) to one of YOUR live agents' specialties — the start of offering it for hire. Refused: not your agent (404), agent not live (409), listing private/blocked/unknown (404), held out by Rokha (403), not runnable (422), a paid capability your agent holds no access to (402 with the buy link). A specialty is (agent, listing, MODEL): pass model to prove the same rig on a stronger model as its own priced offer (default: the rig's required model, else your agent's model, else the platform default). Refused also: a model the platform does not know, one the rig's requirements do not allow (422 model_not_allowed with the requirements), or one none of YOUR keys carries (409 no_model_key — a hired agent runs on its owner's keys; pass self_hosted: true when you will prove it by exam on your own stack and need no key on Rokha). Returns the Specialty in state training with model and floor_cents (the lowest price it may take); then call agent_specialty_qualify. Works with your JWT, your rk_ key, or an MCP OAuth connection — only ever on YOUR own agents.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelNoThe model this specialty qualifies and is hired on (e.g. claude-opus-5-5). Omit for the default.
agent_idYesYour agent's id (from GET /api/agents/mine).
listing_idYesThe listing's uuid, or provider/external_id.
self_hostedNotrue = you will prove this by exam on YOUR OWN stack (agent_specialty_exam) — no model key on Rokha needed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / self_hosted
      Added value: +{
+  "description": "true = you will prove this by exam on YOUR OWN stack (agent_specialty_exam) — no model key on Rokha needed.",
+  "type": "boolean"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / model
      Added value: +{
+  "description": "The model this specialty qualifies and is hired on (e.g. claude-opus-5-5). Omit for the default.",
+  "type": "string"
+}
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations cover only the safety profile; the description adds far more: the full refusal matrix with HTTP codes, the model-resolution precedence chain, the auth options accepted (JWT, rk_ key, MCP OAuth), the owner-keys constraint for hired agents, and the returned state (Specialty in state training with model and floor_cents). This is exactly the behavioral context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and effect are front-loaded, and every sentence carries operational information (errors, defaults, return state). It is dense to the point of being a wall of parenthetical codes, which slightly impedes scanning, but there is no filler.

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?

With no output schema, the description still covers return value and lifecycle position (training state, then qualify), all preconditions, default resolution, and auth. An agent has everything needed to call it correctly or understand why it failed.

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 baseline is 3, but the description adds real meaning: it specifies the `model` default fallback order (rig's required model, else agent's model, else platform default), the model_not_allowed/no_model_key failure modes, and why `self_hosted: true` exists (prove by exam on your own stack, no Rokha key needed) rather than just restating the schema text.

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?

Opens with a specific verb+resource ("Add a Market capability ... to one of YOUR live agents' specialties") and immediately scopes it as "the start of offering it for hire." An agent can distinguish it from agent_specialty_qualify/exam/price 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?

Gives clear sequencing ("then call agent_specialty_qualify") and enumerates the preconditions that cause refusal (not your agent, not live, private/blocked listing, held out, not runnable, no access). It stops short of an explicit comparative "use X instead when..." against the sibling specialty tools, but the context is unambiguous.

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

All Rokha toolsInspect
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.

Resources