# CyberBrick (npm · cyberbrick-mcp)

Drive the Bambu Lab CyberBrick desktop app: connect devices, edit firmware config, flash.

- Trust score: 75/100 (medium)
- Change this week: +4
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- npm · `cyberbrick-mcp`: 75/100 (this document), [markdown](https://verifymcp.io/servers/jarvisluk-cyberbrick-mcp/cyberbrick-mcp.md), [page](https://verifymcp.io/servers/jarvisluk-cyberbrick-mcp/cyberbrick-mcp)

## Channel facts

- Registry: `npm`
- Package: `cyberbrick-mcp`
- Version: `0.4.0`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Supply Chain Security**: 98/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - No install/post-install scripts declared.
  - 30 of 95 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 45/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 10 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 73/100
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 4916 tokens (~119/item across 41 items; 41 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 37/100
  - Stability observed for 11 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 98/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 93% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - All 2 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
  - An AI judge read all 42 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the CyberBrick MCP server?

CyberBrick runs locally as an npm package, launched with npx -y cyberbrick-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add jarvisluk-cyberbrick-mcp -- npx -y cyberbrick-mcp
```

### Cursor

```json
{
  "mcpServers": {
    "jarvisluk-cyberbrick-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "cyberbrick-mcp"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "jarvisluk-cyberbrick-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "cyberbrick-mcp"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add jarvisluk-cyberbrick-mcp -- npx -y cyberbrick-mcp
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "jarvisluk-cyberbrick-mcp": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "cyberbrick-mcp"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add jarvisluk-cyberbrick-mcp --command npx --arg -y --arg cyberbrick-mcp
```

### Hermes

```yaml
mcp_servers:
  jarvisluk-cyberbrick-mcp:
    command: "npx"
    args: ["-y", "cyberbrick-mcp"]
```

### Netclaw

```json
{
  "McpServers": {
    "jarvisluk-cyberbrick-mcp": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "cyberbrick-mcp"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add jarvisluk-cyberbrick-mcp -t stdio -c npx -a -y cyberbrick-mcp
```

### Other

```json
{
  "mcpServers": {
    "jarvisluk-cyberbrick-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "cyberbrick-mcp"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-05 (score 75, +1)

No change was recorded against any check on this day. Stability & Change Management went from 33 to 37. That category is still filling its 30-day observation window: 10 days of observed history at the previous scan, 11 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-11-03 (score 74, +1)

No change was recorded against any check on this day. Stability & Change Management went from 27 to 30. That category is still filling its 30-day observation window: 8 days of observed history at the previous scan, 9 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-11-01 (score 73, +1)

No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-30 (score 72, +1)

No change was recorded against any check on this day. Stability & Change Management went from 13 to 17. That category is still filling its 30-day observation window: 4 days of observed history at the previous scan, 5 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-28 (score 71, +1)

No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-26 (score 70, +1)

No change was recorded against any check on this day. Stability & Change Management went from 0 to 3. That category is still filling its 30-day observation window: 0 days of observed history at the previous scan, 1 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-25 (score 69)

First indexed and scored.

## MCP tools (41)

### `cb_health` (~33 tokens)

Check CyberBrick app health: CDP endpoint live, app version, renderer bridge access, device count. Call this first.

### `cb_launch` (~139 tokens)

Launch the CyberBrick desktop app with the CDP debug port (9223). Reuses a reachable CDP endpoint. If the app is already running without the debug port, it fails unless kill_existing=true (the app enforces a single-instance lock) — killing it discards unsaved work, so get the user's OK first. NOTE: must run from an unsandboxed shell.

Input parameters:

- `kill_existing` (boolean): Kill a running CyberBrick instance (without the CDP port) before launching. Only with the user's OK — unsaved work is lost.
- `timeout_ms` (number): Max wait for the CDP endpoint to come up.

### `app_logs` (~184 tokens)

Read the CyberBrick app's renderer console, captured by this MCP server since it attached (ring buffer, 5000 lines; lines that mention tokens/keys/PINs/certs are never stored). Poll with since=<lastSeq> to follow long tasks such as flash_config with hardwareMappings (upgrade → send config → pairing). Per-message B0 traffic and keepalives are hidden unless includeNoise. Read-only.

Input parameters:

- `grep` (string): Case-insensitive regex filter on the line text.
- `includeNoise` (boolean): Include per-message B0 traffic and keepalive lines.
- `levels` (array): Console levels to keep, e.g. ['error','warning'].
- `limit` (integer): Max lines returned (the newest matching ones).
- `since` (integer): Return only lines with seq > since (use lastSeq from the previous call).

### `device_list` (~26 tokens)

List devices known to the CyberBrick app (zustand deviceListStore). Read-only.

### `device_detail` (~44 tokens)

Get detailed status for one device: connect state, loader mode, connection-pool entry. Read-only.

Input parameters:

- `device_id` (string, required): Device identifier as reported by device_list.

### `device_pool_state` (~23 tokens)

Inspect the internal Bluetooth connection pool (size + ids). Read-only.

### `device_request` (~113 tokens)

Call a read-only window.app.local method: isInLoader, getDeviceById, or sendGetMessage with a read-only B0 command (DEVICE_STATUS, GET_DEVICE_CONFIG, GET_BOARD_INFO, GET_BOARD_TYPE, GET_DEVICE_WIFI_MAC, SYSTEM_VERSION, MPY_PROJECT_INFO, MPY_CHECKSUM_INFO). Any other method or command is refused.

Input parameters:

- `args` (array): JSON-serializable arguments.
- `method` (string, required): Method name on window.app.local, e.g. getDeviceById.

### `board_info` (~66 tokens)

Aggregated board info for one device: firmware/loader versions, hardware string, project string, SN, board type — read via B0 SYSTEM_VERSION + GET_BOARD_INFO + GET_BOARD_TYPE.

Input parameters:

- `device_id` (string, required): Device identifier (bluetoothDeviceId) from device_list.

### `device_status` (~43 tokens)

ADC / channel status vector (DEVICE_STATUS, 10 bytes). Read-only.

Input parameters:

- `device_id` (string, required): Device identifier (bluetoothDeviceId) from device_list.

### `device_config_get` (~55 tokens)

Board config file metadata (GET_DEVICE_CONFIG reqType=GET_FILE_INFO). file_size=0 means no config stored. Read-only.

Input parameters:

- `device_id` (string, required): Device identifier (bluetoothDeviceId) from device_list.

### `device_config_block` (~71 tokens)

Fetch one board-config file block (GET_DEVICE_CONFIG reqType=GET_FILE_BLOCK). Use after device_config_get reports file_size>0. Read-only.

Input parameters:

- `device_id` (string, required): Device identifier (bluetoothDeviceId) from device_list.
- `index` (integer, required): Block index (0-based).

### `device_config_read` (~72 tokens)

Read back the whole board config file (GET_FILE_INFO + every GET_FILE_BLOCK), trimmed to file_size, with its MD5 (compare with flash_config's md5) and the parsed config JSON. Read-only.

Input parameters:

- `device_id` (string, required): Device identifier (bluetoothDeviceId) from device_list.

### `device_ble_state` (~73 tokens)

Live BLE link state per device: GATT connected, store vs. manager status, pool membership, loader mode and the BluetoothDevice connectionCount. connectionCountOk=false means every reconnect (enterLoader during upgrades, BLE drops) will fail with RECONNECTION_INTERRUPTED — fix with device_ble_heal. Read-only.

### `device_ble_heal` (~78 tokens)

Reset a non-finite (NaN/undefined) BluetoothDevice.connectionCount to 0 on live devices — the state markBluetoothDevice would have set — so the app's reconnect logic works again without power-cycling the board. No BLE I/O. Run before upgrades/pairing when device_ble_state shows connectionCountOk=false.

### `connect_scan_ports` (~74 tokens)

Scan connectable ports

Enumerate Web Serial ports and Web Bluetooth devices currently available to the CyberBrick app. Read-only — does not pair or connect. Use this to tell the user what hardware can be connected right now.

Input parameters:

- `includeKnownDevices` (boolean): Also list B0-known (paired/known) receivers from the app device list.

### `connect_bluetooth` (~218 tokens)

Add device via Bluetooth

Drive the app's real add-device flow (BluetoothDeviceManager.requestDevice — the same one the MyDeviceDialog UI uses): starts a BLE scan filtered to CyberBrick devices (companyIdentifier 17882, manufacturer data prefix [99]), then auto-selects the matching device so the chooser resolves without UI. After it resolves, the app marks the device and the caller can verify with device_list. MUTATING (pairs a device).

Input parameters:

- `deviceId` (string): Select the board with this deviceId (from device_list; on macOS a Chromium pseudo-address, not the chip MAC). Takes precedence over deviceName — use it for boards that share a name or were renamed (p…
- `deviceName` (string): Prefer a device whose advertised name matches this substring (case-insensitive). If omitted, the first discovered CyberBrick device is selected.
- `timeoutMs` (integer): How long to wait for the chooser to resolve before cancelling. The B0 probe after selection has its own budget.

### `connect_serial` (~123 tokens)

Select USB/Serial port

Ask the app's main process to auto-select a Web Serial (USB-C) port (window.electron.ipcRenderer.autoSelectSerialPort, strategy "first") and return its metadata plus the BLE-connected board it belongs to (USB serial number = chip MAC, matched against each board's GET_DEVICE_WIFI_MAC). In this app the serial link only serves the USB flash (rescue flasher) feature — config, pairing, upgrades and every other device tool go over Bluetooth, so this does not make a board usable by the other tools. Opens nothing on the board.

### `firmware_config_get` (~39 tokens)

Get current firmware config

Read the current firmwareConfig from the app store (window.app.useFirmwareConfigStore). This is what would be burned to the board. Read-only.

### `firmware_edit_actions` (~97 tokens)

List firmware editing actions

Semantic documentation for the firmware-config store actions (window.app.useFirmwareConfigStore) — the surface behind firmware_config_edit. Returns enums (receiverKey, actuator, device, configType), grouped action names, and per-action arg signatures. Pass action=<name> to get the doc for one action. Read-only, no app connection required.

Input parameters:

- `action` (string): Return the doc for a single action name instead of the full catalog.

### `firmware_config_set` (~61 tokens)

Set full firmware config

Replace the whole firmware config via the app store's setFirmwareConfig. Immediately applies to the app store (and the next burn). MUTATING — writes to the app's firmware config.

Input parameters:

- `config` (required): Full firmware config object (mirror of firmware_config_get).

### `firmware_config_edit` (~115 tokens)

Edit one config field

Call a single firmware store action on the app store (e.g. updateReceiverChannel, updateSenderChannel, changeSwitchState). Immediately applies to the editor config. MUTATING. Use firmware_edit_actions first to get the exact arg signature (positional args, enums like receiverKey/actuator) for the action you want.

Input parameters:

- `action` (string, required): Store action name, e.g. updateReceiverChannel. See firmware_edit_actions.
- `args` (array): Positional arguments for the action, in the documented order.

### `firmware_config_reset` (~31 tokens)

Reset config to empty defaults

Clear the firmware config to empty defaults via the app store's resetFirmwareConfig. Immediately applies. MUTATING.

### `firmware_config_load_template` (~125 tokens)

Load built-in template into editor

Replace the editor config with one of the app's built-in project templates (same data as project_create, in the app's UI language). By default keeps the loaded project's id/name so project_save overwrites it; keepIdentity=false loads it as an unsaved new config. Marks the editor modified; nothing is written to the project list or board until project_save / flash_config. MUTATING.

Input parameters:

- `keepIdentity` (boolean): Keep the current project id/config_name/design_id/region.
- `template` (string, required): Built-in template key (same set as project_create).

### `flash_config` (~353 tokens)

Burn firmware config to board

Write a firmwareConfig to the board. Default: the app's SET_DEVICE_CONFIG file protocol (FILE_INFO(md5,size) → chunked FILE_BLOCK via sendGetMessage) — works for a lone receiver, burns firmwareConfig if given else the current editor config, to exactly one target device (ambiguous or unmatched targets are refused). The device must be connected (else DEVICE_NOT_CONNECTED → call connect_bluetooth). Returns {ok, verified, bytes, chunkSize, blocks, md5, readback} — verified=true when the board reports the written size — or {stage, ...} on failure. Passing hardwareMappings switches to the app's runSendConfigTask (burns a saved project, needs a sender board; never creates a project). That path can also upgrade firmware / MPY / loader first — preview with flash_check and pass confirm=true only after the user approved those upgrades. Executes immediately — OVERWRITES the board's stored config. MUTATING / writes to hardware.

Input parameters:

- `confirm` (boolean): runSendConfigTask path only, required true: set only after the user approved the upgrades flash_check reports.
- `firmwareConfig` (object): Config object to burn (defaults to the current editor config). File-protocol path only.
- `firmwareListId` (string): runSendConfigTask path only: saved project id to burn (defaults to the editor's current config id; must exist in project_list).
- `hardwareMappings` (array): Opt into the high-level runSendConfigTask path (requires a sender board).
- `target` (object): Which device to target — pass exactly one field. If omitted, the app must know exactly one device; ambiguous or unmatched targets are refused.

### `flash_check` (~123 tokens)

Preview upgrades for a hardwareMappings burn

Dry-run of flash_config's hardwareMappings path: calls the app's checkDeviceConfigSync and reports, per board, which firmware / MPY / loader upgrades runSendConfigTask would run before sending the config and pairing. Nothing is written. Use it to get the user's consent for upgrades first. upgradeTargets is exactly what the run executes (the app's log may still mention a loader upgrade it then skips). Read-only.

Input parameters:

- `firmwareListId` (string): Saved project id (defaults to the editor's current config id).
- `hardwareMappings` (array, required)

### `flash_mpy` (~297 tokens)

MicroPython firmware update

Run a MicroPython firmware update via the app's updateLoaderFirmwareMpy (START_MPY_UPDATE). Writes mpy.img and REBOOTS the board. DESTRUCTIVE — requires confirm=true after explicit user approval. Default path upgrades to the built-in RC MPY (mpyType=1); passing userMpyConfig targets a design MPY. Experimental: the built-in path still needs live validation (see docs/MPY固件链路笔记.md).

Input parameters:

- `checksum0` (string): MPY checksum for the upgrade check; defaults to empty (built-in path).
- `confirm` (boolean, required): Must be true. Set it only after the user has explicitly approved this specific upgrade on this specific device.
- `designId` (string)
- `eraseFirmwareConfig` (boolean): Also erase the board RC config after upgrade (app behavior step 13).
- `mpyType` (integer): 0 = user_mpy (design MPY, requires userMpyConfig), 1 = cb_rc (built-in RC MPY).
- `region` (string)
- `target` (object): Which device to target — pass exactly one field. If omitted, the app must know exactly one device; ambiguous or unmatched targets are refused.
- `userMpyConfig`: Design MPY config {title, microPython:{uniKey, checkSum0}} — required when mpyType=0.

### `flash_firmware` (~233 tokens)

Full system firmware upgrade

Run a full system firmware flash (SYSTEM_UPGRADE) via the app's updateLoaderFirmwareMpy with shouldUpgradeFirmware=true. Executes immediately — multiple reboots, CAN BRICK the device if interrupted. Requires firmwareBinaryB64: the MCP does not replicate the app's cloud package fetch (auth headers + certificate decryption are out of scope), so you must supply the .bin yourself (base64). Requires confirm=true after explicit user approval. DESTRUCTIVE.

Input parameters:

- `confirm` (boolean, required): Must be true. Set it only after the user has explicitly approved this specific upgrade on this specific device.
- `firmwareBinaryB64` (string, required): Base64 of the firmware .bin image. Required — the app fetches its own copies only via its cloud check, which this tool does not replicate.
- `region` (string)
- `target` (object): Which device to target — pass exactly one field. If omitted, the app must know exactly one device; ambiguous or unmatched targets are refused.
- `targetVersion` (string): Target firmware version string (recorded in checkResult.upgradeFirmwareTo).

### `flash_test` (~102 tokens)

Send test/control command

Send a control/test command to a connected device via the app's sendTestCommand. Executes immediately — drives an actuator/output on the board. MUTATING.

Input parameters:

- `command` (object, required): sendTestCommand payload {config, actuator, set_value, receiver, data}; deviceId is taken from target.
- `target` (object): Which device to target — pass exactly one field. If omitted, the app must know exactly one device; ambiguous or unmatched targets are refused.

### `project_state` (~62 tokens)

Get project page state

Read the app's current context: active route (hash), project list summary, and editor state (isModified, configType). Returns a nextTools list of the tools relevant right now — call this first when working with CyberBrick projects, then act. Read-only.

### `project_list` (~76 tokens)

List projects

List CyberBrick projects via the app store's getShowList(): configId, type, configName, designLink, lastModifiedTime. Pass include=full to fetch one project's complete config body via getFirmwareById. Read-only.

Input parameters:

- `id` (string): Return the full record for this configId instead of the list summary.

### `project_create` (~106 tokens)

Create project from template

Create a new CyberBrick project from a built-in template (the app's createProjectFromTemplate flow: template config + addFirmware). Templates: forklift, truck, forklift_and_truck, ball_car, official_remote, none, custom. MUTATING (adds a project to the app's list).

Input parameters:

- `name` (string): Project name (max 31 chars, as the app validates). Defaults to the template's own name.
- `template` (string, required): Built-in template key.

### `project_import` (~126 tokens)

Import project from JSON content

Import a project from its JSON content (the app's importProjectFromFileContent flow): validates config_version (rejects files newer than the app supports), forces design_id/region to app defaults, adds to the project list. Pass the file content as a string — read the file yourself first. MUTATING (adds a project).

Input parameters:

- `content` (string, required): Project JSON content (a CyberBrick project file exported by project_export or the app).
- `name` (string): Project name; defaults to config_name from the content, else "config". ".json" suffix is stripped.

### `project_export` (~62 tokens)

Export project as JSON content

Export a project's config as JSON content — the same serialization the app's export uses (runtime fields stripped, version stamped). No save dialog; write the returned content to a file yourself. Read-only.

Input parameters:

- `id` (string, required): Project configId (from project_list).

### `project_rename` (~60 tokens)

Rename project

Rename a project via the app store's renameFirmware. MUTATING. Max 31 chars (app validation).

Input parameters:

- `id` (string, required): Project configId (from project_list).
- `name` (string, required): New project name (max 31 chars).

### `project_delete` (~62 tokens)

Delete project

DESTRUCTIVE: permanently deletes the project via the app store's deleteFirmware. This cannot be undone — the project config is removed from the app's persisted list. No confirmation is added by MCP.

Input parameters:

- `id` (string, required): Project configId (from project_list).

### `project_load` (~87 tokens)

Load project into editor

Load a project's config into the app's firmware editor store (setFirmwareConfig(getFirmwareById(id)) + setConfigType), the same thing the app does when you open a project. After loading, use firmware_config_edit to change parameters, then project_save to persist. MUTATING (replaces the current editor config).

Input parameters:

- `id` (string, required): Project configId (from project_list).

### `project_save` (~48 tokens)

Save editor config as project

Persist the current editor config into the project list (the app store's updateFirmware: updates by id, adds if new) and mark the editor as saved. MUTATING (writes the project list).

### `project_open_editor` (~116 tokens)

Open project editor window

Open the project editor (the app's openProjectEditor): loads the config into the editor store, then opens /project/edit?firmwareId=<id> either in a new app window (default, via the app's createWindowWithPath) or by navigating the current window. MUTATING (loads config, opens window).

Input parameters:

- `id` (string, required): Project configId (from project_list).
- `target` (string): "new" opens a separate editor window (app default); "current" navigates the main window.

### `window_list` (~90 tokens)

List app windows

List the CyberBrick app's open windows: `openWindows` is the live truth (CDP page list with titles + hash routes), `storeWindows` is the window-state store's persisted id map (may be stale) — its ids are what window_close accepts. Also reports which window this MCP session is connected to (currentWindowId) and whether its editor has unsaved changes. Read-only.

### `window_close` (~128 tokens)

Close an app sub-window

Close a CyberBrick app window by its windowId (from window_list). Uses the app's own closeSubWindow (window:close-sub-window IPC) — the same path as the window's close button; unsaved changes trigger the app's own confirm dialog, which the MCP does not bypass. The MCP-connected window cannot be closed (REFUSE_CLOSE_CURRENT). Each project_open_editor with target="new" opens one of these — close them to avoid window buildup. MUTATING.

Input parameters:

- `windowId` (integer, required): Window id to close (from window_list). Must not be the current window.

### `window_close_others` (~52 tokens)

Close all sub-windows except current

Close every CyberBrick app window except the one this MCP session is connected to. Use to clean up editor windows accumulated from project_open_editor. Unsaved changes surface the app's own confirm dialogs. MUTATING.

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/jarvisluk-cyberbrick-mcp/cyberbrick-mcp#diagnostics

## Score history

- 2026-11-05: 75
- 2026-11-04: 74
- 2026-11-03: 74
- 2026-11-02: 73
- 2026-11-01: 73
- 2026-10-31: 72
- 2026-10-30: 72
- 2026-10-29: 71
- 2026-10-28: 71
- 2026-10-27: 70
- 2026-10-26: 70
- 2026-10-25: 69

## Common questions

### What is the CyberBrick MCP server?

CyberBrick is an MCP server listed in the public MCP registry as io.github.jarvisluk/cyberbrick-mcp. Drive the Bambu Lab CyberBrick desktop app: connect devices, edit firmware config, flash. This page covers its npm package (cyberbrick-mcp).

### Is the CyberBrick MCP server safe to use?

CyberBrick scores 75 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 5 November 2026. It declares no install or post-install scripts. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the CyberBrick MCP server expose?

CyberBrick exposes 41 tools: cb_health, cb_launch, app_logs, device_list, device_detail, and 36 more. Their descriptions and schemas cost roughly 4,086 tokens of context every time the server is loaded.

### Is the CyberBrick MCP server still maintained?

CyberBrick is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the CyberBrick MCP server under?

CyberBrick declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- npm package: https://www.npmjs.com/package/cyberbrick-mcp
- Socket report: https://socket.dev/npm/package/cyberbrick-mcp
- Repository: https://github.com/jarvisluk/cyberbrick-mcp
- Changelog RSS feed: https://verifymcp.io/servers/jarvisluk-cyberbrick-mcp/cyberbrick-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/jarvisluk-cyberbrick-mcp/cyberbrick-mcp.json
- HTML version of this page: https://verifymcp.io/servers/jarvisluk-cyberbrick-mcp/cyberbrick-mcp