Skip to main content
Glama

Publish a listing to the Rokha Registry

registry_publish

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 ); 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.

Input Schema

NameRequiredDescriptionDefault
nameYeskebab-case slug, ≤64 chars
tagsNoDiscovery tags, e.g. trading, solana.
titleNodisplay name (defaults to the slug)
versionNoYour version string, e.g. 1.2.0.
homepageNoAn https link to the project's home.
metadataNothe artifact: skill_md / harness / rig (≤200KB)
source_idNoUUID 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 in registry search — an exact lookup that never depends on the name. Omitted, the server derives it from the slug when it can.
descriptionYeswhat it does (≤4000 chars) — this is the discovery text
listing_typeYesskill (metadata.skill_md), harness (metadata.harness) or rig (metadata.rig).

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "type": "object"
      +}
  2. Changed4 schema fields changed
    • addedInput schema / properties / homepage / description
      Added value: +"An https link to the project's home."
    • addedInput schema / properties / listing_type / description
      Added value: +"skill (metadata.skill_md), harness (metadata.harness) or rig (metadata.rig)."
    • addedInput schema / properties / tags / description
      Added value: +"Discovery tags, e.g. trading, solana."
    • addedInput schema / properties / version / description
      Added value: +"Your version string, e.g. 1.2.0."
  3. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Well beyond the annotations, it discloses the auth requirement, server-side derivation of the display author, that a caller-supplied `author` is ignored except for superadmins, global uniqueness of the slug under your ownership, and the mutation-vs-update rule. This is exactly the context an agent needs before writing to a shared registry.

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?

The critical constraints (ownership, auth, name uniqueness) are front-loaded ahead of the listing_type breakdown and return-value note. It is a single dense paragraph with heavy em-dash nesting; a short structural break would improve scannability, but little is wasted.

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 9-parameter nested-object mutation with auth and ownership implications, the description covers what an agent cannot infer: who owns the record, how updates are triggered, how listing_type maps to metadata, and what identifiers to retain. Return values are additionally noted even though an output schema exists, which is a bonus rather than a gap.

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 already 100%, so the baseline is 3; the description adds real meaning on top by mapping each listing_type to its required metadata key (skill_md / harness / rig) and spelling out the naming constraint. It leaves tag, version, homepage, and metadata size limits to the schema, which is acceptable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'Publish (or update) YOUR listing in the Rokha Registry', and clarifies the create-or-update duality ('re-publishing your own slug updates it'). It does not name any sibling tool (e.g. registry_adopt, registry_get_skill) to differentiate itself, so it falls short of a 5.

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 establishes clear preconditions and context: requires a logged-in identity with a Bearer JWT, listing is owned by the verified caller, and re-publishing your own slug is the update path. It also disambiguates the 'server' legacy alias. No explicit exclusions or pointer to alternative tools, so not 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.