device-context-protocol/dcp

Developer tools

このページは AI により自動翻訳されています。技術的な詳細は原文をご確認ください。原文を見る

62 stars 3 forks 品質 74 トレンド 17MIT

Repository Install

デバイスコンテキストプロトコル — LLM エージェントを物理的なデバイスにブリッジします。サブ-50バイトフレーム、27.6KBフラッシュ/ESP32で測定された0.6KB RAM、設計による機能スコープ、安全。 MCP への補完.

概要

ドラフトv0.3 — 2026年5月 · ESP32-WROOM-32でハードウェア検証済み LLM エージェントが物理的なデバイスを安全に制御できるプロトコル。ドルクラスのマイクロコントローラまで。意図的なレベル、輸送agnostic、機能-scoped。コンパクトなワイヤ形式(サブ-50バイトフレーム)。自己完結ファームウェア:RAMの1 KB未満、〜28 KBのフラッシュ。 MCP への補完 — 参照ブリッジは DCP ↔ MCP を翻訳するので、MCP ホスト (Claude デスクトップ、Claude コード、IDE アシスタント) はゼロコンフィグを動作します。 MCP は SaaS ツールで優れていますが、WebSocket とランタイムツールのディスカバリーで JSON-RPC を想定しています。 32 KBのRAMを搭載したMCUでは、非スターターです。 DCP は MCP のメンタルモデル (manifest + ツールコール) を維持します。 - コンパクトなCBORワイヤーフォーマットにコンパイル - 静的インテントテーブル(ランタイム交渉なし)を使用して - ブリッジプロセスへの安全執行を移動参照橋は翻訳します、従って箱からMCP互換LMの仕事。 DCPは物理的なハードウェアに最後のマイルです.

概要（AI 翻訳）

** ステータス:** ドラフトv0.3 — 2026年5月 · ESP32-WROOM-32でハードウェア検証済み

LLMエージェントが物理的デバイスを安全に制御できるプロトコルドルクラスのマイクロコントローラまで。ツイート意図的なレベル、交通機関agnostic、機能スコープ。密集したワイヤーフォーマット (サブ-50バイトフレーム) 自己完結ファームウェア:RAMの1 KB以下、〜28 KBのフラッシュ。ツイート MCP への補完 — 参照 Bridge は DCP ⇔ MCP を翻訳するので、MCP のホスト (Claude デスクトップ、Claude コード、 IDEのアシスタント)はゼロ構成を働かせます。

コンテンツ

なぜDCPか。
設計原則
建築
クイックスタート
5つのステップで機能を追加
レシピ - 準備が整った5つのデバイススケルトン
ワイヤーフォーマット・フル SPEC.md
マニフェスト
ロードマップ
デザイン合理的: ドキュメント/RATIONALE.md — なぜ MCP-on-MCUではなく、WoTではなく、なぜマットではないのか。

DCPの理由

MCP は SaaS ツールで優れていますが、WebSocket とランタイムで JSON-RPC を想定しています。ツールの発見。 32 KBのRAMを搭載したMCUでは、非スターターです。

DCP は MCP のメンタルモデル (manifest + ツールコール) を維持します。

コンパクトなCBORワイヤーフォーマットにコンパイル
静的インテントテーブルを使用する(ランタイム交渉なし)
橋梁プロセスへの安全執行を移動

このページは AI により自動翻訳されています。技術的な詳細は原文をご確認ください。

README

以下は原文 README の抜粋です。原文を見る。

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.

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

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

Architecture

GitHub で README 全文を見る

インストール

This server does not publish a one-line install command.

Open the repository installation guide MCP 初心者？mcpskill.org のガイドから始めましょう →

設定

{
  "mcpServers": {
    "smart-lamp": {
      "command": "dcp",
      "args": [
        "serve",
        "C:/path/to/protocol/examples/lamp_manifest.yaml",
        "--simulator"
      ]
    }
  }
}