CyberBrick

Name: CyberBrick
Author: jarvisluk

本地服务

github.com/jarvisluk开发工具05 天前更新

代码仓库

关于 CyberBrick

CyberBrick 是通过 Chrome DevTools Protocol 控制 Bambu Lab CyberBrick 桌面应用的 MCP 服务。它覆盖从设备连接规划到固件配置和刷写的设置流程；指定的破坏性操作需要明确确认。

主要功能

01规划设备连接
02读取设备和连接状态
03编辑固件配置
04管理 CyberBrick 项目
05刷写固件和配置
06查看应用日志和窗口

适用场景

01连接前检查设备
02为设备准备固件设置
03创建或导入 CyberBrick 项目
04明确确认后刷写固件

MCP 相关

它向 MCP 客户端提供调用 CyberBrick 应用 API 的工具。stdio 服务通过 Chrome DevTools Protocol 连接桌面应用。

配置

本地服务的配置在各客户端中通用，复制后粘贴到客户端的 MCP 配置文件即可。

mcp.json · 通用配置

{
  "mcpServers": {
    "jarvisluk-cyberbrick": {
      "command": "npx",
      "args": [
        "-y",
        "cyberbrick-mcp"
      ],
      "env": {
        "CB_CDP_HOST": "<CB_CDP_HOST>",
        "CB_CDP_PORT": "<CB_CDP_PORT>",
        "CB_APP_BINARY": "<CB_APP_BINARY>"
      }
    }
  }
}

启动命令npx -y cyberbrick-mcp

需要配置的环境变量

CB_CDP_HOSTHost of the CyberBrick app's CDP endpoint (default 127.0.0.1)

CB_CDP_PORTPort of the CyberBrick app's CDP endpoint (default 9223)

CB_APP_BINARYCyberBrick executable that cb_launch starts (default /Applications/CyberBrick.app/Contents/MacOS/CyberBrick)

本地服务需要在你的电脑上安装运行环境（如 Node.js 18+）。各客户端的配置文件位置不同，请参考客户端文档。

安装包

npmcyberbrick-mcp0.4.0stdio

工具

收录的工具列表 · 更新于 5 天前

此工具无需参数。

详细介绍

cyberbrick-mcp

English | 简体中文

一个 MCP 服务，通过 Chrome DevTools Protocol 驱动 Bambu Lab CyberBrick 桌面应用（Electron）。

涵盖完整的设备设置工作流：硬件连接规划 → 固件编写 → 刷写。

工具（41 个）

此服务是 CyberBrick 应用之上的轻量直通层：每个工具都会调用应用自身的 API（store 操作 / 设备方法）并立即执行。例外：flash_mpy、flash_firmware，以及带有 hardwareMappings 的 flash_config（会先升级固件）需要 confirm: true，且仅在用户明确同意后设置。对于设备写入操作，target 必须与唯一一台设备完全匹配，否则调用会被拒绝。

只读 / 探测（readOnlyHint: true）

基础设施：cb_health、app_logs（应用控制台日志，用于跟踪升级或配对等长流程）
设备：device_list、device_detail、board_info、device_status、device_config_get、device_config_block、device_config_read（完整回读 + MD5）、device_ble_state（实时 GATT / connectionCount 状态）、device_pool_state、device_request
连接规划：connect_scan_ports
刷写前检查：flash_check（使用 hardwareMappings 刷写将触发哪些固件 / MPY / 加载器升级）
固件读取：firmware_config_get、firmware_edit_actions（全部 60 个操作的语义参数文档）
项目读取：project_state（页面感知 + nextTools 渐进式披露）、project_list、project_export

写入 / 刷写（直接执行，会修改状态）

启动：cb_launch（如果应用运行时没有调试端口，仅当 kill_existing: true 时才会结束该进程）
连接：connect_bluetooth、connect_serial、device_ble_heal（修复 NaN connectionCount，使重新连接无需重启）
固件编写：firmware_config_set、firmware_config_edit、firmware_config_reset、firmware_config_load_template（将内置模板加载到编辑器）
刷写：flash_config（默认使用 SET_DEVICE_CONFIG 文件协议；适用于单个接收器，且不会创建新项目）、flash_mpy（destructiveHint: true）、flash_firmware（destructiveHint: true）、flash_test
项目管理：project_create（6 个内置模板）、project_import、project_rename、project_delete（destructiveHint: true）、project_load、project_save、project_open_editor
窗口：window_list（只读）、window_close、window_close_others

验证脚本

单元测试（无需应用或硬件）：npm test
发布版本检查：node scripts/check_release.mjs [vX.Y.Z]
只读路径：node scripts/verify_readonly.mjs
服务和工具注册：node scripts/mcp_list.mjs
本地冒烟测试（需要应用正在运行）：node scripts/smoke.js
项目管理冒烟测试（创建 → 重命名 → 导出 → 导入 → 加载 → 保存 → 删除）：node scripts/smoke_project.mjs
项目管理 MCP E2E：node scripts/mcp_e2e_project.mjs
RC 汽车端到端示例（发送器 + 接收器映射 → 保存 → 回读断言 → 导出；--flash 会增加刷写和 LED 测试）：node scripts/demo_rc_car.mjs
临时调用任意工具：node scripts/mcp_call.mjs <tool> '<json>' [...]
重新提取模板数据（应用升级后）：python3 scripts/extract_templates.py

运行

需要 Node.js 18+，并且 CyberBrick 桌面应用与其位于同一台机器上。

MCP 客户端配置（JSON），通过 npm 安装：

{
  "command": "npx",
  "args": ["-y", "cyberbrick-mcp"]
}

从本地检出目录运行：

npm install
node src/server.js        # stdio MCP server

CDP 端口

默认使用 127.0.0.1:9223（避开常用的 9222）。可通过 CB_CDP_HOST / CB_CDP_PORT 覆盖。cb_launch 默认启动 /Applications/CyberBrick.app/Contents/MacOS/CyberBrick；可通过 CB_APP_BINARY 覆盖。

安全规则

绝不读取或导出身份验证令牌、私钥或 AES 密钥（connection.js 中的 sanitize 会按键名进行筛选）。
破坏性工具（flash_mpy、flash_firmware）带有 destructiveHint，并要求设置 confirm: true——Agent 必须先向用户说明影响（会写入开发板／重启／可能导致设备无法使用），并征得用户同意。
device_request 仅允许只读方法（isInLoader、getDeviceById，以及针对只读许可列表中命令的 sendGetMessage）。
默认情况下，cb_launch 不会终止已运行的应用（否则会丢失未保存的工作）；只有显式设置 kill_existing: true 才会终止。
刻意不提供：BIND_DEVICE、SET_PRIVATE_KEY、证书流程、PIN 流程（参见 src/core/devices.js 中的 ALLOWED_COMMANDS）。

发布

CI（.github/workflows/ci.yml）会在每次推送到 main 和每个 PR 时运行：在 Node 18/20/22/24 上测试、检查服务启动、检查版本并运行 npm pack --dry-run。

推送 vX.Y.Z 标签会运行 .github/workflows/release.yml：验证 → 发布到 npm（包含来源证明）→ 将 server.json 发布到 MCP Registry → 根据 CHANGELOG 部分创建 GitHub Release。若某个版本已发布，每个步骤都会自动跳过，因此运行失败时只需重新运行即可。

在 package.json / package-lock.json（npm version X.Y.Z --no-git-tag-version）、server.json（两个 version 字段）和 src/server.js 中更新版本号。
在 CHANGELOG.md 中添加 ## [X.Y.Z] - YYYY-MM-DD 部分。
运行 node scripts/check_release.mjs vX.Y.Z——必须通过。
提交，然后运行 git tag vX.Y.Z && git push origin main vX.Y.Z。

带后缀的标签（v1.0.0-rc.1）会以 next dist-tag 发布到 npm，并标记为预发布版本。

一次性设置：

npm：在 npmjs.com 上为此包添加受信任发布者（GitHub Actions、工作流 release.yml、环境 release）。只有在包已存在后才能配置受信任发布，因此首次发布时需要先手动发布一次，或添加 NPM_TOKEN 仓库密钥（npm 自动化令牌）；启用受信任发布后，请移除此密钥。
MCP Registry：无需配置。工作流会使用 GitHub OIDC 登录，这对其运行所在仓库的 io.github.<owner>/ 命名空间有效。