§22 MCP Server Integration

OpenCastor exposes a Model Context Protocol (MCP) server that wraps the RCAN robot runtime as discoverable tools. Any MCP-capable AI agent — regardless of provider or model — can use these tools to observe and command robots through a single, standardised interface.

Auth is provider-agnostic: access level is determined by the token, not the model. A Gemini agent and a Claude Code session with identical tokens have identical access.

§22.1 Installation and startup

Terminal

# Install with MCP support
pip install "opencastor[mcp]"

# Generate a client token
castor mcp token --name "my-agent" --loa 1

# Start the MCP server
export CASTOR_MCP_TOKEN=<token>
castor mcp

# Register with Claude Code (one command)
castor mcp install --client claude --token $CASTOR_MCP_TOKEN

# Dev mode (LoA 3, no token required, local only)
CASTOR_MCP_DEV=1 castor mcp

§22.2 Client configuration

MCP clients are registered in the robot's RCAN config under mcp_clients:. Tokens are stored as sha256: hashes — never raw values.

Terminal

# bob.rcan.yaml — mcp_clients block
mcp_clients:
  - name: "claude-code-laptop"
    token_hash: "sha256:abc123..."   # sha256 of the raw token
    loa: 3                           # admin access
  - name: "gemini-monitor"
    token_hash: "sha256:def456..."
    loa: 0                           # read-only
  - name: "codex-research"
    token_hash: "sha256:ghi789..."
    loa: 1                           # operate

§22.3 Tool catalogue

14 tools across three Level-of-Assurance tiers. Every mutating tool routes through /api/command — the same RCAN-signed path the bridge uses.

Terminal

# LoA 0 — any authenticated client
robot_ping(rrn?)              → gateway reachability + latency
robot_status(rrn?)            → brain state, active model, uptime
robot_telemetry(rrn?)         → full system snapshot
fleet_list()                  → all robots with compliance + LoA level
rrf_lookup(entity_id)         → provenance chain (RRN/RCN/RMN/RHN)
compliance_report(rrn?)       → EU AI Act Art. 11 status report

# LoA 1 — named operate token
robot_command(instruction, scope, rrn?, reason?)
harness_get(rrn?)             → current harness config + flow graph
research_run(rrn?)            → trigger OHB-1 benchmark
contribute_toggle(enabled, rrn?)
components_list(rrn?)         → registered hardware components

# LoA 3 — admin token
harness_set(layers, flow_graph?, rrn?)
system_upgrade(version?, rrn?)
loa_enable(min_loa?, rrn?)

§22.4 LoA → RCAN trust level mapping

MCP LoA tiers map to RCAN protocol trust roles and command scopes. The ESTOP safety invariant is always honoured regardless of LoA.

Terminal

# LoA → RCAN trust level mapping
LoA 0  →  unauthenticated read     (M2M_PEER, read-only scope)
LoA 1  →  standard agent operate   (M2M_PEER, chat/control scope)
LoA 3  →  admin / trusted system   (M2M_TRUSTED, system scope)

# Scope enforcement
robot_command(scope="safety")   → bypasses replay check (ESTOP always honored)
robot_command(scope="control")  → requires LoA ≥ min_loa_for_control
robot_command(scope="system")   → requires LoA 1 minimum
harness_set(...)                → requires LoA 3

§22.5 EU AI Act compliance via MCP

The rrf_lookup and compliance_report tools make EU AI Act Article 11 technical documentation machine-readable. Any authorised agent can reconstruct the full provenance chain programmatically:

Terminal

# Reconstruct full Art. 11 provenance chain via MCP
compliance_report("RRN-000000000001")   # system identity + safety controls
rrf_lookup("RRN-000000000001")          # robot identity, manufacturer, firmware_hash
rrf_lookup("RCN-000000000002")          # Hailo-8 NPU, 26 TOPS, parent: RRN-1
rrf_lookup("RMN-000000000002")          # OpenVLA 7b, apache-2.0, local
rrf_lookup("RHN-000000000001")          # dual-brain harness, rcan_version: 2.2

# → Full Art. 11 record in 5 tool calls, from any AI provider

§22.6 Transport

Phase 1 (current): stdio — works with any local MCP client today. One client per process; token set at startup.
Phase 2 (roadmap): HTTP/SSE — remote clients, multiple concurrent agents, live telemetry subscription. Tracked in #775.

§22.7 Security model

Token hashes use SHA-256; raw tokens are never stored or logged.
LoA enforcement is server-side — not bypassable at the application layer.
Every mutating call routes through RCAN-signed /api/command.
Tokens are revoked by removing the entry from mcp_clients: and restarting the server.
Dev mode (CASTOR_MCP_DEV=1) must never be exposed on a network interface.

§22.8 Conformance

A conformant MCP server implementation MUST:

Enforce LoA gating before any tool execution.
Store client tokens as sha256: hashes only.
Route all mutating tool calls through the RCAN-signed command path.
Honour ESTOP regardless of client LoA.
Expose all 14 tools in the standard catalogue (§22.3).

§22.9 Delegation

MCP tokens function as pre-authorized human delegates. The LoA level declared in mcp_clients: constitutes proof of human authorization — no delegation_chain is required for direct human-configured MCP clients.

Exception — fleet/robot-to-robot MCP: If one robot uses MCP to command another robot (fleet coordination), the command MUST include a delegation_chain with at least one DelegationHop proving human authorization. Maximum depth is 3 hops (RCAN §delegation).

Terminal

# Human-configured MCP client — no delegation_chain needed
mcp_clients:
  - name: "claude-code-laptop"
    token_hash: "sha256:abc..."
    loa: 1   # LoA 1 = human-authorized operator

# Robot-to-robot MCP (fleet) — delegation_chain REQUIRED
# delegation_chain:
#   - robot_rrn: "RRN-000000000001"
#     scope: "control"
#     issued_at: "2026-03-29T22:00:00Z"
#     expires_at: "2026-03-30T22:00:00Z"
#     sig: "<ml-dsa-65 signature>"