DCP — Device Context Protocol

Status: Draft v0.3 — May 2026 · Hardware-validated on ESP32-WROOM-32

A protocol that lets LLM agents safely control physical devices, down to dollar-class microcontrollers.

Intent-level, transport-agnostic, capability-scoped. Compact wire format (sub-50-byte frames). Self-contained firmware: under 1 KB of RAM, ~28 KB of flash.

Complementary to MCP — a reference Bridge translates DCP ↔ MCP so any MCP host (Claude Desktop, Claude Code, IDE assistants) works zero-config.

Contents

• Why DCP?
• Design principles
• Architecture
• Quickstart
• Add a feature in 5 steps
• Recipes — five ready-to-flash device skeletons
• Wire format · full SPEC.md
• Manifest
• Roadmap
• Design rationale: docs/RATIONALE.md — why not MCP-on-MCU, why not WoT, why not Matter.

Why DCP?

MCP is excellent for SaaS tools, but assumes JSON-RPC over WebSocket and runtime tool discovery. On an MCU with 32 KB of RAM, that's a non-starter.

DCP keeps MCP's mental model (manifest + tool calls) but:

• compiles to a compact CBOR wire format
• uses a static intent table (no runtime negotiation)
• moves safety enforcement to a Bridge process

A reference Bridge translates DCP ↔ MCP, so any MCP-compatible LLM works out of the box. DCP is the last mile to physical hardware.

Why this matters in one chart: the protocol's schema decides how many hallucinated or adversarial calls are stopped before any byte reaches a device. DCP catches all six categories at the wire layer; the others catch what their existing schema happens to cover.

Design principles

1. Intent, not register. set_brightness(50%), not write_pwm(pin=5, duty=128).
2. Units in the protocol. Every number declares a unit. No ambiguity.
3. Static intent table. Manifest known at compile time; runtime is pure binary.
4. Safety lives in the Bridge. Devices trust the Bridge; LLMs never see raw GPIO.
5. Idempotent by default. Non-idempotent intents must declare themselves.
6. Transport-agnostic. UART, BLE, MQTT, USB-CDC, WebSocket — one frame.

Architecture

The Bridge is the sole trust boundary. On every call it issues and verifies capability tokens, enforces range/type/unit checks from the manifest, and supports dry-run as a wire-format primitive. Devices remain simple enough to fit on commodity microcontrollers; everything the LLM is allowed to do is enforced before any byte traverses the device boundary.

Validated on real hardware

As of v0.3 the reference firmware is measured-validated on two physical boards — an ESP32-WROOM-32 dev board over CH340 USB-Serial, and an ESP32-S3 (LILYGO T-Panel S3) over the S3's native USB-Serial/JTAG — both at 115 200 baud: