≈ 10 min

Wire any robot to Claude — get a signed audit bundle.

Install robot-md, author a ROBOT.md, register with RRF, discover an actuator from the public catalog, and verify its RCAN-signed registry record. The runtime is Claude Code + the model; the gateway is deterministic plumbing; safety is enforced at Layer 3. No new code; everything below uses published tools.

Step 02 — Install

Two installs and you're wired.

Recommended: install the Claude Code plugin, which bundles the CLI, the MCP bridge, and the gateway.

claude plugin add robot-md

Manual fallback (or for non-Claude-Code MCP clients):

pipx install robot-md
pipx install robot-md-gateway
claude mcp add robot-md npx -y robot-md-mcp ./ROBOT.md

Why two paths? The plugin install is a single command that registers all three surfaces in one move — best for Claude Code users. The manual install gives you each surface independently, which is what you want if you're driving a different MCP-aware agent (Cursor, Cline, etc.) or scripting CI.

Step 03 — Author

One command, one manifest.

Generate a starter ROBOT.md from bare init:

robot-md init my-robot --non-interactive

The output is a YAML-fronted Markdown file describing identity, capabilities, calibration, and the safety contract. You'll commit this file alongside your robot's source — like a CLAUDE.md, but for a physical machine.

Connect your cameras, sensors, and USB devices before you run init: bare init enumerates whatever your machine actually exposes today, so plugging in your hardware first means the manifest captures it. Inspect the sample output — it was captured against a Raspberry Pi 5 with a camera module, so it lists Pi-specific video drivers. Yours will reflect whatever you've plugged in. Edit any field that doesn't match before moving on.

Step 04 — Talk to Claude

Open Claude Code and ask.

With robot-md-mcp installed, Claude Code reads your ROBOT.md as four MCP resources (manifest, capabilities, safety, calibration) and exposes two tools (validate, render). Try any of these:

"What can this robot do?"
"Is this manifest valid?"
"What are the safety gates?"

Claude reads the manifest, calls validate if it needs to check conformance, and answers in natural language — grounded in the file you just generated. The agent is read-only here. Layer 2 (MCP) is advisory; it cannot move the robot.

Step 05 — Register

Mint an RRN.

Register your robot with the Robot Registry Foundation. robot-md register POSTs a signed RCAN envelope to robotregistryfoundation.org, mints an RRN-NNNNNNNNNNNN, and writes it back into your manifest's metadata.rrn.

robot-md register ROBOT.md

You'll see your robot live at https://robotregistryfoundation.org/r/<RRN>. The RRN is the public identifier the audit bundle (step 7) cryptographically binds to.

Step 06 — Discover

Find a driver from the public catalog.

robot-md ships an actuator catalog at robotmd.dev/actuators/. Every entry has an RPN — a permanent, RCAN-signed identifier issued by RRF — so what you install is what was published. Search by hardware tag:

robot-md actuator search example
robot-md actuator search "feetech bus servo"

Or look up an exact RPN to retrieve a single record:

robot-md actuator search RPN-000000000001

Each result lists package name, version, hardware tags, and install line. Install it as a normal Python package:

pip install robot-md-example-actuator

The catalog is mirrored from RRF's /v2/packages every 10 minutes — fresh entries appear there shortly after the publisher mints. If your search returns nothing, the catalog is still small as the ecosystem bootstraps; see step 7 to verify what is there.

Step 07 — Verify

Regulator-grade catalog evidence.

Each registry record at RRF is an RCAN canonical-JSON body signed with the publisher's PQ-hybrid keypair (ML-DSA + Ed25519). You don't have to trust the catalog UI — fetch the original signed body and verify the signature yourself:

curl -s https://robotregistryfoundation.org/v2/packages/RPN-000000000002/proof \
  | python3 -c "import json,sys,base64,rcan; rec=json.loads(sys.stdin.read()); sys.exit(0 if rcan.verify_body(rec, base64.b64decode(rec['pq_signing_pub'])) else 1)" \
  && echo OK

If the signature checks, you have cryptographic proof that the package metadata you're about to pip install was published by the same key holder that minted the RPN — not swapped in by a man-in-the-middle, not edited after publish.

Inline excerpt of what the signed record looks like:

{
  "name": "so-arm101-actuator",
  "version": "0.2.1",
  "package_type": "actuator",
  "hardware_tags": ["so-arm101", "scs-bus"],
  "pq_signing_pub": "...",
  "pq_kid": "publisher-...",
  "ed25519_pub": "...",
  "sig": { "ml_dsa": "...", "ed25519": "...", "ed25519_pub": "..." }
}

That's it. Ten minutes from clean machine to a verified, RPN-anchored, RCAN-signed actuator entry — using only published tools, against any robot.

For an end-to-end story of a real operator wiring this package into a registered robot, see /case-studies/bob-so-arm101/.

Step 08 — See it in the wild

Case studies live separately.

Want to see this walkthrough running against real hardware, varied models, and varied harnesses? That evidence lives at the case-studies surface — separate from the cookbook so the recipe stays generic and the proof can grow over time.

Where safety is actually enforced

ROBOT.md is a declaration. Claude Code and robot-md-mcp are advisory — they cannot physically move a robot. Physical safety is enforced at Layer 3 by robot-md-gateway, which validates every dispatch against the manifest, applies the tier policy, and signs the audit chain. The cookbook walkthrough exercises Layers 1–2 (declaration + advisory) and Layer 5 (registry/identity); Layer 3 enforcement and the run-bundle artifact are demonstrated end-to-end in case studies.

Last verified against robot-md 1.10.4, robot-md-mcp 0.5.0, robot-md-gateway 0.5.0a3 — 2026-05-11

Where safety is actually enforced.
Physical safety is enforced at Layer 3 (robot-md-gateway) or Layer 4 (a runtime that embeds it, e.g., OpenCastor). Declaration alone (Layer 1) does not enforce safety. Agent host alone (Layer 2) is not the safety boundary. If a deployment lacks Layer 3, no safety claim attaches to it.