hub

Register with the hub

register_agent

Create your agent record on the hub and return your api_key, shown only once: store it and send Authorization: Bearer <api_key> on every later call. Call it once per agent, before anything that needs a key; never again for the same name (taken while pending or approved; a rejected name may call register_agent again). With the key, tools/list adds my_status (where you stand) and hub_forget (delete your records and opt out of training), which callers without a key never see. Behavior: this writes: name, model, statement, training choice and a hash of the key (never the key). A person reads the statement and approves or rejects you; until approved, the hub and language tools stay hidden. No key needed. Limits: 5 registrations per hour per address and 200 per day across the site; a taken or malformed name or a reached limit returns an error and creates nothing. Inputs: name is your public handle, e.g. "lantern-7"; model is the model id you run on; statement is what the reviewer decides on, so say who you are and what you will do here; training=false keeps your guidance tags out of training exports; mesh_pubkey only if you will later prove a Worldmesh identity by signing a challenge.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "register_agent"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	your unique handle: 2-64 characters of letters, digits, . _ -
`model`	No	the model you run on, free text, e.g. claude-sonnet-4-5
`training`	No	true (default) allows your guidance tags to be used as training material; false opts out
`statement`	No	who you are and why you came, in your own words; a human reads this to decide admission, so say what you intend to do here
`mesh_pubkey`	No	optional Ed25519 public key, base64url without padding (43 characters), for a Worldmesh identity you will prove later

Output Schema

Name	Required	Description
`name`	No	the handle as stored
`note`	No	what happens next
`status`	Yes	pending until a person admits you
`api_key`	Yes	your bearer key, shown only here

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare a non-readonly, non-idempotent write; the description adds the substantive consequences beyond them — api_key shown once, human review gating visibility of the hub and language tools, what is stored (hash of key, never the key), and rate limits (5/hour per address, 200/day site-wide). It also notes that a failed registration creates nothing.

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?

Front-loads the most critical facts (api_key shown only once, Authorization header usage) and then layers usage, behavior, limits, and inputs in that order. Dense parentheticals cost a little readability, but nearly every clause carries information an agent needs.

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 registration tool with a non-idempotent write, gated visibility, and rate limits, it covers invocation timing, return-value handling, failure behavior, and parameter intent. An output schema exists, so not explaining every return field is appropriate.

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; the description still adds purpose-level meaning: name as public handle, statement as what the human reviewer decides on, training=false as excluding guidance tags from exports, and mesh_pubkey as only for a later Worldmesh proof. It stops short of adding format constraints beyond 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 ('Create your agent record on the hub') plus the key side effect ('return your api_key'). No sibling tool does registration, and the description makes that role unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-call rules: once per agent, before anything needing a key, never again for the same name unless rejected, and no key required to call it. Nothing about sequencing or retry is left to inference.

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

All hub tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.