registry-broker-skills: skill files that teach a coding assistant to query the Universal Agentic Registry

The gap registry-broker-skills fills: assistants that know nothing about live agent inventory

An AI coding assistant can write the client code for an agent-to-agent call, but it cannot tell you which agents exist right now, what protocol they speak, or whether one is reachable. That information lives in registries, and the registries disagree with each other. Fetch.ai agents sit in AgentVerse. Anthropic's Model Context Protocol servers sit in MCP listings. Google's A2A has its own directory, and ERC-8004 puts verification on-chain. A developer asking an assistant to "find a trading bot" gets a plausible-looking code sample and no inventory.

This repository addresses that by shipping instruction files rather than a runtime. The README describes the contents as "skill definitions" for the Universal Agentic Registry, and states the file format is plain markdown that Claude Code, Claude Desktop, OpenAI Codex, ChatGPT, Cursor, OpenClaw and ClawHub can each consume in their own way. The audience is developers who already work inside one of those assistants and want registry lookups to happen in the same window, without switching to a browser or writing a client against each protocol's API.

The repository is not the registry. The Universal Agentic Registry itself is hosted at hol.org/registry, and the protocols the README lists as aggregated include AgentVerse, Virtuals, A2A, MCP, ERC-8004, x402 Bazaar, OpenRouter, NANDA, Near AI, OpenConvAI, XMTP, ANS, PulseMCP and HCS-10. What you clone here is the client-side teaching material plus a CLI wrapper.

How a skill file and the registry broker API fit together

The mechanism is deliberately shallow. SKILL.md contains the instructions an assistant reads, and the repository also publishes the same surface as a package export: package.json maps "./skill" to "./SKILL.md" and "./skill.json" to "./skill.json". An assistant that supports project instructions loads the markdown; one that wants structured metadata reads skill.json, whose shape is defined by schemas/skill.schema.json.

Underneath the instructions, the CLI talks to the Registry Broker API. package.json depends on @hol-org/rb-client at version 0.1.157, and the CLI itself is exposed as two binaries, hol-registry and holr, both pointing at ./bin/cli.js. Chat functionality pulls in @xmtp/node-sdk, and viem is present for the on-chain paths. The README says chat uses XMTP by default, which tells you the messaging leg is not a plain HTTP POST.

Data flow for a search is therefore: assistant reads SKILL.md, decides the user wants inventory, shells out to the CLI or calls the API, the broker fans the query across the aggregated protocols, and results come back keyed by UAID. The README's resolve example uses the form uaid:aid:fetchai:agent123, so a UAID is the cross-protocol identifier you carry between calls. Nothing in the repository caches registry state locally, which means every lookup reflects whatever the hosted broker currently holds.

Installing registry-broker-skills and running a first search

The README's quickest path is the published npm package run through npx, with no clone and no install step. Node 18 or newer is required, per the engines field in package.json. The first command searches the aggregated inventory for agents matching a phrase.

npx @hol-org/registry search "trading bot"

You should get back matching agents with their identifiers and protocol origins. To see how much inventory exists before trusting a narrow query, run the stats subcommand, which the README documents as returning platform statistics.

npx @hol-org/registry stats

Resolving a single agent takes a UAID copied from a search result. The README's example uses a Fetch.ai identifier.

npx @hol-org/registry resolve uaid:aid:fetchai:agent123

Chatting is the step that needs credentials. The README sets REGISTRY_BROKER_API_KEY in the environment before invoking chat, and notes the transport defaults to XMTP.

export REGISTRY_BROKER_API_KEY="your-key"
npx @hol-org/registry chat uaid:aid:fetchai:agent123 "Hello!"

Before sending as an agent rather than to one, the README requires Moltbook ownership verification through the claim subcommand, passing MOLTBOOK_API_KEY, and states that the same verification unlocks broker registration. Balance is a separate subcommand, and it is worth running before a batch of chats because the README frames chat as consuming credits.

MOLTBOOK_API_KEY="mb_xxxxx" npx @hol-org/registry claim
npx @hol-org/registry balance

For assistants rather than shells, the repository ships runnable examples. package.json wires npm run search to examples/search-and-chat.js, npm run register to examples/register-agent.js and npm run ledger to examples/ledger-auth.js, so the scripted path is available without reading the CLI source.

Where registry-broker-skills stops being the right tool

The largest constraint is that the registry is a hosted service. If hol.org is unreachable, or the broker API changes shape, the skill files still load and the CLI still starts, but every lookup fails. Nothing in the repository layout suggests a local mirror or an offline mode, and the README does not document one. Teams with air-gapped environments or a policy against querying third-party indexes should treat this as a blocker rather than a caveat.

Chat is gated twice. It requires REGISTRY_BROKER_API_KEY, and sending as an agent additionally requires Moltbook verification through the claim subcommand with MOLTBOOK_API_KEY. The README does not document what happens when a key expires mid-session, nor does it describe retry behaviour for a failed XMTP handshake. Anyone building on chat should plan for a failure path the documentation leaves open.

The aggregation claim is also worth reading carefully. The README lists 14 protocols, and the repository description says 72,000+ agents across 14+ protocols. Those protocols have different notions of what an agent is: a Virtuals entry is a tokenized agent, an MCP entry is a server exposing tools, an HCS-10 entry is a Hedera consensus participant. A single search returns a mixed set, and the broker's normalisation is the only thing making them comparable. If your use case depends on protocol-specific metadata that does not survive normalisation, query the source registry directly instead.

Finally, this is a young package surface. The current version is 1.5.2, and the most recent releases listed are Zenodo metadata and end-to-end trigger builds from 2026-02-23 rather than feature releases. The last push to the repository was on 2026-08-31. Neither fact says the API is unstable, but the release history gives you little to read for a stability signal.

Universal Agentic Registry against a single-protocol MCP directory

The obvious alternative is to skip the aggregation layer and query one registry directly. If you only need MCP servers, installing a single-protocol MCP directory client or reading PulseMCP's own listing gives you richer per-server detail, because nothing is lost in translation between the source schema and a cross-protocol one. The trade-off is scope: you get one protocol's inventory and no way to ask a question that spans protocols.

The difference in approach is where the normalisation happens. A single-protocol directory keeps native fields and lets the caller learn that schema. The Universal Agentic Registry normalises entries from AgentVerse, A2A, ERC-8004, XMTP and the rest into a common shape addressed by UAID, then exposes one API over the result. That is what makes a cross-protocol search possible and what makes protocol-specific nuance the first thing to disappear.

A second alternative is to treat the repository as documentation only. The markdown skill format is portable, and the README notes it is consumable as project instructions, so an assistant can be taught the broker's API shape without the CLI being installed at all. That path costs you the convenience subcommands and the examples, and it puts the responsibility for authentication and error handling on whatever you write yourself.

Licence, upgrade cost and the skill-publishing track

The package is Apache-2.0, and the LICENSE file sits at the repository root alongside CITATION.cff and .zenodo.json. Apache-2.0 permits commercial use and modification and includes a patent grant, which matters if you vendor SKILL.md into an internal assistant configuration. It also requires that you preserve notices. This is a description of the licence text, not legal advice; check it against your own distribution model.

Upgrade cost is low for the instruction files and higher for the CLI. SKILL.md is markdown, so pulling a newer version means re-reading it and re-checking that the commands it teaches still match the CLI. The CLI is a normal npm dependency, currently 1.5.2, and it pins @hol-org/rb-client at 0.1.157, so a broker-side change can arrive through a transitive dependency bump rather than through this repository. If you pin the package version, you also pin the client version.

The repository also covers publishing rather than only consuming. The README documents a skills subcommand group: skills config, skills init with --dir, --name and --version, skills lint with --dir, and skills list with --name and --limit. A separate repository, hashgraph-online/skill-publish, is named as the publishing action. So the same CLI that searches the registry is also the tool for getting your own skill manifest into it, validated against schemas/skill.schema.json.

Editorial conclusion

Adopt it if you want an assistant to reach agent inventory across AgentVerse, MCP, A2A and the other listed protocols through one API, and if you accept that the index itself is a hosted service you do not control. Skip it if you need a self-contained registry, since this repository holds skill definitions and a CLI, not the registry. Before committing, run npx @hol-org/registry stats, confirm the credit balance your key maps to, and read schemas/skill.schema.json to check that your manifest validates.

Frequently asked questions

Official sources

1. hashgraph-online/registry-broker-skills on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases