Skip to main content
Glama
Sign In

Rokha

by ai.rokha
OverviewDiscussionsAdmin

Find any Rokha tool

tools_catalog
Read-only

tools/list carries the core set only; this finds the rest, and every tool is callable whether or not it is listed. No arguments: the toolsets with counts. query: words matched against every tool's name, title and description — one line per hit (name · title · toolset). toolset: one set in full (build · agents · sell · lab · signet · tasks · about). name: one tool's complete definition, inputSchema included — call it next. To list a set from connect time put ?toolset=build,agents (or all) on the server URL.

Input Schema

NameRequiredDescriptionDefault
nameNoAn exact tool name, e.g. 'rig_author' — returns its full definition.
queryNoWords to match, e.g. 'schedule a rig' or 'sell a rig'. Case-insensitive; every word must appear.
toolsetNoA set name: core, build, agents, sell, lab, signet, tasks, about, or all.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous value: -"Words to match, e.g. 'schedule a rig' or 'paper trade'. Case-insensitive; every word must appear."New value: +"Words to match, e.g. 'schedule a rig' or 'sell a rig'. Case-insensitive; every word must appear."
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
  3. Changed1 schema field changed
    • changedInput schema / properties / toolset / description
      Previous value: -"A set name: core, build, agents, sell, lab, signet, tasks, about, sponsors, or all."New value: +"A set name: core, build, agents, sell, lab, signet, tasks, about, or all."
  4. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare a safe read (readOnlyHint=true, destructiveHint=false) and nothing here contradicts that. The description adds real behavioral context beyond annotations: the default listing is core-only, every tool is callable even when unlisted, and a `query` hit returns one line in the form name · title · toolset.

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?

It is tightly front-loaded — the core-only limitation comes first, then each argument's effect — with no filler sentences. The telegraphic style ('No arguments: the toolsets with counts.') is efficient though slightly clipped for a first-time reader.

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?

For a three-parameter discovery tool with an output schema, this covers all four invocation modes and the returned shape well enough to call correctly. The only blemish is that the set list in the prose omits `core` and `all` that the schema's `toolset` description does include, a small inconsistency an agent must reconcile.

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 a 3 is the floor, but the description genuinely adds meaning: `query` words are matched against every tool's name, title *and* description and returns one line per hit, `toolset` returns 'one set in full', and `name` returns the complete definition including inputSchema. This goes past the per-parameter schema strings rather than repeating them.

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 the resource (the tool catalog) and contrasts it with the built-in `tools/list`, which only carries the `core` set: 'this finds the rest'. It then enumerates the four distinct modes (no args, `query`, `toolset`, `name`), so an agent knows exactly what each call returns 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?

It gives concrete routing guidance per mode — search by words, load a full set, load one definition and 'call it next' — plus an alternative mechanism (?toolset=... on the server URL, or `all`) for connect-time listing. It never states when *not* to use this tool (e.g. that `tools/list` should be preferred for core), 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.

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

Resources