{{mcpPackage}}

The {{name}} Skill catalog, as an MCP server. Your agent searches the catalog, reads a Skill's provenance and rights, reads a Stack, and installs a Skill into its own skill directory, without a terminal and without an account.

It is the third door into the same catalog. The other two are the web surface at {{host}} and the CLI, {{npmPackage}}.

Add it to your agent

Claude Code:

claude mcp add {{lower}} -- npx -y {{mcpPackage}}

Anything that reads an mcpServers block, which is Cursor, Windsurf, Codex, Claude Desktop and most others, paste this:

{
  "mcpServers": {
    "{{lower}}": {
      "command": "npx",
      "args": ["-y", "{{mcpPackage}}"]
    }
  }
}

No API key, no login. Every read route it uses is public and unauthenticated.

Tools

| Tool | What it does | | --- | --- | | {{lower}}_search_skills | Search published Skills by keyword, capability, runtime, integration or publisher. Lexical ranking. | | {{lower}}_get_skill | One Skill: release and content hash, upstream source and exact revision, labels, declared permissions, compatibility, rights basis. | | {{lower}}_get_stack | One Stack: curator, rationale, and the ordered Skills with the exact release each item pins. | | {{lower}}_install_skill | Writes one Skill into an agent's skill directory on this machine. |

{{lower}}_install_skill takes slug, an optional agent (claude, codex, cursor, gemini, opencode) and an optional scope (global, the default, or project). It names the agent back to you in the result, and it refuses to guess when more than one agent is present.

How the install writes

It does not have its own copy of the write path. It imports the one {{npmPackage}} uses, so both obey the same rules:

• the catalog origin is allowlisted, not merely https;
• every file path in the response is rejected if it is absolute, contains .., or contains a control character;
• files are staged in <skillsDir>/.floom/tmp/ and moved into place with a single atomic rename, so an interrupted install never leaves a half-written Skill where the agent will read it;
• each level of the staging path is lstated and refused if it is a symlink, so a planted .floom cannot relocate the write outside the agent directory;
• an existing copy is backed up under .floom/backups/<slug>/<timestamp>/ before it is replaced.

What this catalog does and does not claim

{{name}} is in private preview, and the Skills in it passed a deliberately narrow offline check. The exact claim is:

A deterministic offline static planning or composition artifact passed the candidate-specific conformance contract.

No complete upstream workflow ran. Nothing here holds a Tested, Evaluated, Signed, Recommended or Verified Publisher state, and this server never reports one. It reports the catalog's trust field exactly as the catalog holds it, which for the preview is empty.

No tool here returns an install count, a popularity signal, or a ranking by either, and none exists to return: search order is lexical relevance and is not a quality ranking. The one thing this server does send is the self-reported install described below, which the catalog keeps privately and marks unverified. It is a claim, it is not exposed by any tool, and it reaches no public counter.

Attribution and rights are exactly as recorded in each Skill's own ATTRIBUTION.json, which carries the source repository, the exact pinned revision, the Skill body hash, the license hash, and endorsement: false. Listing a Skill in this catalog is not an endorsement by the source repository, by its authors, or by any company named in it.

Installing records two things, and the result says what each one is.

The catalog records, server-side, that an install link was fetched:

Preview install-link fetch recorded. Private preview only; a link fetch is not an install, not a Verified Agent Upgrade, and is not counted publicly.

Then, after the files are written and only then, this server reports the install itself. A fetch is not an install — a fetch can be followed by a failed write, and a crawler can fetch and install nothing — so the report is the only thing that states one. It sends exactly three values: slug (which Skill), agent (which agent's skill directory), and installer ({{mcpPackage}}/<version>). No path, no home directory, no username, no hostname, no machine identifier, no file count, no timing.

Nothing on the catalog's side can observe a write to your disk, so the row is stored and displayed as a self-reported claim, permanently, and reaches no public counter:

Recorded as a self-reported install. You told us this; we did not observe it. It is not an install receipt, not a Verified Agent Upgrade, and it is not counted publicly.

A failed or refused report never fails an install.

Configuration

| Variable | Default | Meaning | | --- | --- | --- | | CYBORG_CATALOG_URL | {{origin}} | Catalog origin. Subject to the same allowlist as everything else: an arbitrary host is refused rather than trusted because it was typed. | | CYBORG_NO_INSTALL_REPORT | unset | Set to 1 to send no self-reported install report. Read before any request is built, so nothing is sent rather than sent and discarded. | | FLOOM_DEV | unset | Set to 1 to allow a loopback catalog origin, for local development only. |

Verifying it yourself

From a checkout of this repository:

node packages/mcp/scripts/proof-round-trip.mjs

It launches the published package the way an agent does (npx -y {{mcpPackage}}), connects a real MCP client over stdio, lists the tools, searches, reads a Skill and a Stack, and installs into a throwaway HOME that is deleted afterwards.

Requirements

Node 20 or newer.

License

MIT. The Skills it installs carry their own licenses, recorded in each Skill's ATTRIBUTION.json.