CyberBrick
NPM · CYBERBRICK-MCP
Drive the Bambu Lab CyberBrick desktop app: connect devices, edit firmware config, flash.
Available components
Last scanned (2 hours ago)
Scores higher than 50% of npm servers
Category IoT and Hardware
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. How we score → Why this is hard to score →
Supply Chain Security98
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- No install/post-install scripts declared.Pass
- 30 of 95 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency45
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 10 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability73
- AI-judged instruction clarity (good).Pass
- 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. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management37
- Stability observed for 11 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage98
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 93% of tool parameters carry a description.Partial
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- All 2 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
- An AI judge read all 42 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 5 Nov 26 +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.
- 3 Nov 26 +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.
- 1 Nov 26 +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.
- 30 Oct 26 +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.
- 28 Oct 26 +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.
- 26 Oct 26 +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.
- 25 Oct 26 69
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 5 Nov 2026 · Analysed npm/cyberbrick-mcp@0.4.0
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | npm |
Background: How many MCP packages publish verified provenance →
Dependencies 95 packages
| Packages resolved | 95 |
|---|---|
| Stale | 30 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
app_logs ~184
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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). |
No output schema declared.
No examples provided.
board_info ~66
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.
| Name | Type | Req | Description |
|---|---|---|---|
| device_id | string | yes | Device identifier (bluetoothDeviceId) from device_list. |
No output schema declared.
No examples provided.
cb_health ~33
Check CyberBrick app health: CDP endpoint live, app version, renderer bridge access, device count. Call this first.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
cb_launch ~139
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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. |
No output schema declared.
No examples provided.
connect_bluetooth Add device via Bluetooth ~218
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).
| Name | Type | Req | Description |
|---|---|---|---|
| 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. |
No output schema declared.
No examples provided.
connect_scan_ports Scan connectable ports ~74
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.
| Name | Type | Req | Description |
|---|---|---|---|
| includeKnownDevices | boolean | – | Also list B0-known (paired/known) receivers from the app device list. |
No output schema declared.
No examples provided.
connect_serial Select USB/Serial port ~123
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.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
device_ble_heal ~78
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.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
device_ble_state ~73
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.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
device_config_block ~71
Fetch one board-config file block (GET_DEVICE_CONFIG reqType=GET_FILE_BLOCK). Use after device_config_get reports file_size>0. Read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| device_id | string | yes | Device identifier (bluetoothDeviceId) from device_list. |
| index | integer | yes | Block index (0-based). |
No output schema declared.
No examples provided.
device_config_get ~55
Board config file metadata (GET_DEVICE_CONFIG reqType=GET_FILE_INFO). file_size=0 means no config stored. Read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| device_id | string | yes | Device identifier (bluetoothDeviceId) from device_list. |
No output schema declared.
No examples provided.
device_config_read ~72
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.
| Name | Type | Req | Description |
|---|---|---|---|
| device_id | string | yes | Device identifier (bluetoothDeviceId) from device_list. |
No output schema declared.
No examples provided.
device_detail ~44
Get detailed status for one device: connect state, loader mode, connection-pool entry. Read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| device_id | string | yes | Device identifier as reported by device_list. |
No output schema declared.
No examples provided.
device_list ~26
List devices known to the CyberBrick app (zustand deviceListStore). Read-only.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
device_pool_state ~23
Inspect the internal Bluetooth connection pool (size + ids). Read-only.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
device_request ~113
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.
| Name | Type | Req | Description |
|---|---|---|---|
| args | array | – | JSON-serializable arguments. |
| method | string | yes | Method name on window.app.local, e.g. getDeviceById. |
No output schema declared.
No examples provided.
device_status ~43
ADC / channel status vector (DEVICE_STATUS, 10 bytes). Read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| device_id | string | yes | Device identifier (bluetoothDeviceId) from device_list. |
No output schema declared.
No examples provided.
firmware_config_edit Edit one config field ~115
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.
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | yes | Store action name, e.g. updateReceiverChannel. See firmware_edit_actions. |
| args | array | – | Positional arguments for the action, in the documented order. |
No output schema declared.
No examples provided.
firmware_config_get Get current firmware config ~39
Read the current firmwareConfig from the app store (window.app.useFirmwareConfigStore). This is what would be burned to the board. Read-only.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
firmware_config_load_template Load built-in template into editor ~125
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.
| Name | Type | Req | Description |
|---|---|---|---|
| keepIdentity | boolean | – | Keep the current project id/config_name/design_id/region. |
| template | string | yes | Built-in template key (same set as project_create). |
No output schema declared.
No examples provided.
firmware_config_reset Reset config to empty defaults ~31
Clear the firmware config to empty defaults via the app store's resetFirmwareConfig. Immediately applies. MUTATING.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
firmware_config_set Set full firmware config ~61
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.
| Name | Type | Req | Description |
|---|---|---|---|
| config | – | yes | Full firmware config object (mirror of firmware_config_get). |
No output schema declared.
No examples provided.
firmware_edit_actions List firmware editing actions ~97
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.
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | – | Return the doc for a single action name instead of the full catalog. |
No output schema declared.
No examples provided.
flash_check Preview upgrades for a hardwareMappings burn ~123
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.
| Name | Type | Req | Description |
|---|---|---|---|
| firmwareListId | string | – | Saved project id (defaults to the editor's current config id). |
| hardwareMappings | array | yes | – |
No output schema declared.
No examples provided.
flash_config Burn firmware config to board ~353
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.
| Name | Type | Req | Description |
|---|---|---|---|
| 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. |
No output schema declared.
No examples provided.
flash_firmware Full system firmware upgrade ~233
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.
| Name | Type | Req | Description |
|---|---|---|---|
| confirm | boolean | yes | Must be true. Set it only after the user has explicitly approved this specific upgrade on this specific device. |
| firmwareBinaryB64 | string | yes | 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). |
No output schema declared.
No examples provided.
flash_mpy MicroPython firmware update ~297
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).
| Name | Type | Req | Description |
|---|---|---|---|
| checksum0 | string | – | MPY checksum for the upgrade check; defaults to empty (built-in path). |
| confirm | boolean | yes | 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. |
No output schema declared.
No examples provided.
flash_test Send test/control command ~102
Send a control/test command to a connected device via the app's sendTestCommand. Executes immediately — drives an actuator/output on the board. MUTATING.
| Name | Type | Req | Description |
|---|---|---|---|
| command | object | yes | 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. |
No output schema declared.
No examples provided.
project_create Create project from template ~106
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).
| Name | Type | Req | Description |
|---|---|---|---|
| name | string | – | Project name (max 31 chars, as the app validates). Defaults to the template's own name. |
| template | string | yes | Built-in template key. |
No output schema declared.
No examples provided.
project_delete Delete project ~62
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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Project configId (from project_list). |
No output schema declared.
No examples provided.
project_export Export project as JSON content ~62
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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Project configId (from project_list). |
No output schema declared.
No examples provided.
project_import Import project from JSON content ~126
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).
| Name | Type | Req | Description |
|---|---|---|---|
| content | string | yes | 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. |
No output schema declared.
No examples provided.
project_list List projects ~76
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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | – | Return the full record for this configId instead of the list summary. |
No output schema declared.
No examples provided.
project_load Load project into editor ~87
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).
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Project configId (from project_list). |
No output schema declared.
No examples provided.
project_open_editor Open project editor window ~116
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).
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Project configId (from project_list). |
| target | string | – | "new" opens a separate editor window (app default); "current" navigates the main window. |
No output schema declared.
No examples provided.
project_rename Rename project ~60
Rename a project via the app store's renameFirmware. MUTATING. Max 31 chars (app validation).
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | Project configId (from project_list). |
| name | string | yes | New project name (max 31 chars). |
No output schema declared.
No examples provided.
project_save Save editor config as project ~48
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).
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
project_state Get project page state ~62
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.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
window_close Close an app sub-window ~128
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.
| Name | Type | Req | Description |
|---|---|---|---|
| windowId | integer | yes | Window id to close (from window_list). Must not be the current window. |
No output schema declared.
No examples provided.
window_close_others Close all sub-windows except current ~52
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.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
window_list List app windows ~90
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.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
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.
npm · cyberbrick-mcp
claude mcp add jarvisluk-cyberbrick-mcp -- npx -y cyberbrick-mcp
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.