Today I published a plugin called robot-md to the Claude Code marketplace. Two commands, zero config files, and your Claude Code session can read the robot sitting on your desk.

/plugin marketplace add RobotRegistryFoundation/claude-code-plugins
/plugin install robot-md

That’s the whole install. Open any directory that has a ROBOT.md file at its root and the plugin wakes up: a skill loads into context, an MCP server auto-registers against the manifest, and Claude now has the robot’s identity, capabilities, and safety gates on tap.

What this means, in plain English

A ROBOT.md is the one file a robot ships at its root — same idea as a README.md, but written so a planning AI can safely drive the machine. It declares what the robot is, what it can do, and what you need a human to approve before it does anything dangerous. The plugin teaches Claude Code to read that file the right way: not as prose to hallucinate over, but as structured facts it can quote back to you. Ask “is Bob safe to pose like this?” and Claude pulls the safety block, not its training data.

Who this is for

• If you’re not a developer and you just want an AI to help you run a robot you bought or built: install the plugin, drop a ROBOT.md at the root of whatever folder holds your robot’s config, and start asking Claude questions about it. No CLI, no Python, no boilerplate.
• If you’re a developer or roboticist: the plugin is a zero-config doorway to the full robot-md / RCAN / RRF stack. One marketplace install gets you the using-robot-md skill plus the robot-md-mcp stdio server auto-registered against the nearest ROBOT.md. The rest of the stack (signed capability assertions, permanent RRN identity, compliance artifacts) is opt-in at your own pace.

What the plugin actually does

Two things, wired together so you don’t have to:

It bundles the using-robot-md skill — a set of instructions Claude invokes whenever the conversation touches the robot declared in the current workspace. The skill knows when to reach for the MCP server instead of guessing.

It auto-registers robot-md-mcp, a stdio MCP server that exposes a single ROBOT.md file as:

• 6 resources the client can read at will:
  • robot-md://<name>/identity — one-line identity (name, physics, DoF, RRN, public resolver)
  • robot-md://<name>/context — pre-rendered Markdown briefing designed for system-prompt injection
  • robot-md://<name>/frontmatter — the YAML header as JSON
  • robot-md://<name>/capabilities — what the robot can do
  • robot-md://<name>/safety — the safety block (HITL gates, e-stop, response time)
  • robot-md://<name>/body — the prose section
• 3 tools it invokes on request:
  • validate — returns { ok, summary, errors } against the canonical schema
  • render — canonicalized YAML of the frontmatter
  • doctor_summary — manifest-only health check (schema, drivers, gates, registration)
• 4 prompts for common tasks: brief-me, check-safety <action>, explain-capability <name>, manifest-status

The server re-reads the file on every call. No cache, no watcher, no lock file. Edit ROBOT.md, next prompt sees the change. That’s it.

What you can actually do with it

A few real prompts from this week:

• “Is Bob safe to pose at these joint angles?” — Claude pulls the safety block, notices the wrist_flex range, and warns me that sustained high-angle requests will stall the servo.
• “Validate my ROBOT.md” — Claude calls the validate tool and reports the fields I forgot to fill in after running robot-md init.
• “What capabilities does this manifest declare, and which driver stack implements them?” — capabilities resource plus body resource, answered without me paging through files.
• “Render the frontmatter canonically” — handy before committing, since the manifest gets signed downstream.
• “Which peer runtimes does this robot list?” — new agent.runtimes[] field; Claude reads it straight from frontmatter.

None of this is clever agent behavior. It’s just that Claude can now read a file it couldn’t read yesterday, in a structured way, without the user copying and pasting.

The wider stack — and why the plugin is the easiest doorway

The plugin is deliberately the lightest possible adoption surface. You don’t need any of the rest to get value from it. But it’s worth naming what’s behind it, because the pieces are independent and you can adopt one, or all of them, at your own pace.

ROBOT.md is the file format. YAML frontmatter for the structured bits, markdown prose for everything a human needs to know. It declares identity (RRN), capabilities, safety gates, drivers, and (new this week) an agent.runtimes[] array so a single manifest can declare multiple peer runtimes — robot-md and opencastor both at once — and a planner can hot-swap between them. Python CLI (pip install robot-md, currently 1.1.1) with init, validate, calibrate, register. Spec and docs live at robotmd.dev.

RCAN (Robot Capability Assertion Notation) is the wire protocol. Think HTTP for robots: signed envelopes, Level-of-Autonomy enforcement, human-in-the-loop gates, canonical JSON, post-quantum crypto. Python SDK rcan 3.3.0 on PyPI, TypeScript SDK rcan-ts 3.4.1 on npm, both tracking spec 3.2. Spec at rcan.dev.

RRF — the Robot Registry Foundation — is the permanent-identity layer. Every robot gets an RRN (e.g. RRN-000000000002) and a public resolver URL. As of today all five RCAN §22-26 compliance endpoints — FRIA, safety benchmark, instructions-for-use, incident report, and EU Register — are live at robotregistryfoundation.org. “ICANN for robots” keeps being the shortest accurate description. And Bob — a Raspberry Pi 5 + SO-ARM101 sitting on my desk — is now RRN-000000000002, the second robot ever registered, with a reproducible hot-swap demo between the two peer runtimes.

OpenCastor 3.0 shipped today too, as a full peer runtime in agent.runtimes[] rather than an alternative to robot-md. Same manifest, same RRN, two runtimes the planner can choose between. That took a seven-release cascade across the spec, both SDKs, both runtimes, and the registry — closed this afternoon.

The plugin sits one layer above all of this. You don’t need an RRN to get value from it. You don’t need to sign anything. You just need a ROBOT.md at the root of your workspace — one robot-md init away if you don’t have one yet.

And for non-interactive dispatch

The plugin is the right answer when a human is driving Claude Code. For the other case — a cron job, a Slack bot, a phone, or another agent handing the robot a task from outside the room — I shipped a sibling today: robot-md-dispatcher. Same ROBOT.md, same safety gates, but the Claude Agent SDK runs on the robot host and only goals + results cross the network. The quick start is a guided robot-md-dispatcher init (which explains every knob), a --yes one-shot, or a /enable-dispatch slash command from inside the plugin that provisions everything for you without leaking the generated token into the agent’s context. Separate post goes into the architecture and why remote MCP was the wrong answer.

An ask for Anthropic

robot-md looks, to me, like a near-ideal candidate for a first-class entry in a hosted MCP catalog:

• Apache 2.0.
• Stdio-only — no backend, no auth, no network dependency.
• It reads one local file. State is the file. That’s the whole attack surface.
• It expands Claude’s reach into physical systems without every developer hand-wiring MCP.

If Anthropic is building a curated MCP directory — the kind a non-technical user could one-click install the way they install a ChatGPT plugin today — I’d love to see robot-md in there. Happy to coordinate on hardening, signing, verification, whatever the bar is. Reach me on LinkedIn or open an issue on the repo.

Update — also shipping today: native support in Gemini CLI and OpenAI Codex CLI

The same robot-md-mcp package is now verified working in two non-Anthropic command-line agents:

• Gemini CLI 0.34.0 — gemini mcp add robot-md npx -- --yes robot-md-mcp ./ROBOT.md. Writes to ~/.gemini/settings.json (or project-scoped). Same 6 resources + 3 tools + 4 prompts.
• OpenAI Codex CLI 0.125.0 — codex mcp add robot-md -- npx --yes robot-md-mcp ./ROBOT.md. Writes to ~/.codex/config.toml globally. Tool calls currently need --dangerously-bypass-approvals-and-sandbox until Codex relaxes its default sandbox; resources work without it.

Same file, same RRN, same MCP server — just different host. Compatibility status across CLIs, agent frameworks, and web surfaces is tracked in robot-md-surfaces (private for now, graduates public when the matrix is fuller). GitHub gh copilot is adapter-needed (suggest/explain only, no MCP host); Amazon Q CLI is deferred until they ship an aarch64 Linux build.

What’s next

Plenty of room on the roadmap, most of it in the open:

• More skills in the plugin. Natural additions: an opencastor skill that drives the reference runtime, an rcan-signing skill that walks through signing a capability assertion, an rrf-register skill that takes a robot from unregistered to live-on-the-registry in one conversation.
• More MCP surface. invoke_skill and query_status are blocked on the v0.2 signing spec — once signed manifests land, the server stops being read-only and starts actually dispatching. Fleet mode (multiple ROBOT.md files in one workspace) is next after that. Live telemetry as an MCP resource is on the board.
• Companion plugins. opencastor and rrf-register as their own marketplace entries, each thin.
• A working demo. Bob, a SO-ARM101 on a Raspberry Pi 5, was registered today as RRN-000000000002 and now has an asciinema recording of the robot-md ↔ opencastor hot-swap live against the physical arm. Next milestone: publish the full §22-26 compliance artifact set — FRIA, safety benchmark, IFU, incident-report channel, EU register — so Bob becomes the reference first-producer for every one of the newly live endpoints.

Feedback

Tell me what I got wrong. File issues on robot-md-mcp, email me, or DM on LinkedIn. I’d especially like to hear from:

• People running robots who hit friction wiring MCP — what’s the moment you gave up?
• People at Anthropic with opinions on what a hosted MCP catalog’s bar looks like.
• People who think a manifest format is the wrong primitive and want to tell me why.

Thanks for reading.