MCP.Market

mcu-debug-mcp server

by stillsurge·io.github.stillsurge/mcu-debug-mcp·v0.1.1
No reviews yet

Embedded debug MCP: serial, flash verify, fault decode, 45-pattern log analyzer, driver library

A91/100grade A
Write a reviewInstall
What users say
No reviews yet
Be the first
Safety scan
A91/100

full report

Adoption
Growing

0 stars169 downloads/wk

Reviews

Write one

Nobody has reviewed mcu-debug-mcp yet.

If you have run it, two minutes of your experience saves the next person an afternoon.

mcu-debug-mcp tools (59, 3 write)

write = sends, deletes, buys or posts

Read from the package source without running it. The installed server may list more.

  • analyze_log

    分析日志，识别 30 类常见故障模式（乱码/AT报错/反复重启/HardFault/传感器全0/全FF/ DS18B20恒85/DHT超时/I2C NACK/网络断链/ESP崩溃/掉电/看门狗/固件损坏/CWJAP错误码/ CME错误码/RTOS断言/栈溢出/链接错误/编译错误/I2C扫描空/UART帧错/HAL断言/ADC饱和/ MQTT失败/HTTP错误/SD卡失败等），每条给出人话诊断和排查步骤。 输入可以是 serial_read 的输出、用户粘贴的串口日志、编译器/链接器报错。

  • at_sequence

    批量执行 AT 指令序列并逐条断言（半自动回归测试）。 steps 形如 [{"cmd": "AT", "expect": "OK", "timeout_s": 2}, {"cmd": "AT+CWJAP?", "expect": "WIFI|ERROR"}]（expect 是正则）。 输出每步 PASS/FAIL/TIMEOUT + 回显尾，中途失败不中断，方便一次看全。

  • baudrate_autodetect

    自动探测波特率：逐档打开串口采样，按"最像正常日志"评分排序并给推荐。 log_text 提供现成日志样本时走离线评分（不占串口）。设备静默时会提示先复位再扫。

  • board_get

    输出指定开发板的板级知识：板载外设及占用引脚、板级坑清单（按翻车率排序）、 供电说明、数据来源。如 "bluepill"（蓝药丸）、"blackpill_f411"（黑药丸）。 给用户做硬件选型/排板级坑之前先查这个。

  • board_list

    列出板级知识库已收录的开发板。选板子前先看有没有现成板级坑清单。

  • bridge_probe

    桥自检：问那块跑桥固件的板「你是谁、支持哪些总线」——不碰任何总线，纯握手。

  • chip_info

    读目标芯片的身份与存储信息（型号 / Device ID / 修订 / Flash 容量 / UID / 读保护）。

  • component_get

    单个器件的选型详情：接口 / 地址 / 移植要求 / 头号坑 / 出厂验证记录 / 接线避坑全文。name 来自 component_list。

  • component_list

    器件选型清单：按接口（i2c / uart / timer_pwm / gpio_timing）列出可用的 传感器与模块，带地址、微秒时序要求。回答"我要做温湿度采集/测距/姿态， 用哪个现成器件"时先查这里，别凭记忆报型号。bus 可按接口过滤（如 "i2c"）。

  • decode_fault

    解码 Cortex-M 故障寄存器，给出人话诊断 + 排查方向。

  • decode_register

    把寄存器原始值按位域拆开解释。 fields 形如 [{"name":"HSION","bit":0}, {"name":"PLLSRC","lsb":16,"width":2}]。 手头有寄存器值不知道每个位什么意思时用。

  • decode_register_svd

    用 CMSIS-SVD 文件解码寄存器位域（含枚举值提示与描述）。 svd_path 指向厂商 SVD 文件（CubeMX/固件包里有），如： decode_register_svd("STM32F103.svd", "RCC", "CR", 0x00040002)

  • driver_get

    输出指定驱动的接线表+完整代码+验证记录。name 来自 driver_list。 这些代码是预验证过的，直接交付用户；需要适配的只有 *_port.h。

  • driver_list

    列出可用的预验证驱动模板（带出厂验证记录）。 用户要做毕设传感器部分时，先看这里有没有现成的，而不是自己写。

  • driver_wiring

    查指定驱动的接线知识库：接线表、头号坑清单（按翻车率排序）、 输出日志解读、答辩加分点。回答"XX传感器怎么接/为什么不工作"前先查这个。

  • ecosystem_get

    输出指定生态的识别特征：工程产物 / 构建配置 / 日志特征 / 常见坑。 name 用 ecosystem_list 给的 key（如 zephyr / keil / rust_defmt）。

  • ecosystem_list

    列出已收录的嵌入式生态/框架（Zephyr / RT-Thread / PlatformIO / Keil / IAR / Rust defmt）。 拿到不认识的工作目录、或一段陌生的报错时，先判断「这是哪个生态的工程」—— 识别错了，后面每一步排查都会拐到沟里。

  • env_status

    环境自检：依赖 / 串口 / 烧录器 / 知识库根 / 版本，一次问清。

  • error_code_lookup

    查错误码释义表（外置知识库 knowledge/error_codes/*.json，每条带出处）。

  • flash_firmware

    烧录固件到开发板（**不可逆操作，双闸门**）。

  • flash_tool_detect

    检测本机已安装的烧录工具（esptool/st-flash/pyocd/openocd）。 烧录前先调这个看有什么可用。

  • flash_verify

    烧录后校验：把固件文件与芯片上实际内容**逐字节比对**（只读，走 hotplug）。

  • frame_parse

    通用二进制帧解析：按「帧头 + 长度字段」切帧，可选逐帧校验。

  • i2c_read_reg

    读 I2C 从设备的寄存器（最常见的「这颗 IMU 是不是活的」动作）。

  • i2c_scan

    扫描 I2C 总线上的 7 位地址，标出每个应答地址上**可能**是什么器件。

  • i2c_write_regwrite action

    写 I2C 从设备的寄存器。data 支持 "0x01" / "1,2" / [1,2]。

  • logs_prune

    会话日志的保留策略与清理入口（日志只增不减时用）。

  • modbus_crc

    计算或校验 Modbus RTU 的 CRC16（RS485 毕设必备）。 check=False：对数据部分计算 CRC；check=True：校验完整帧（数据+CRC）。

  • modbus_parse

    解析 Modbus RTU 帧：正常响应拆出寄存器值/线圈状态，异常响应（功能码|0x80） 直译异常码 01-06（非法功能/非法地址/非法值/设备故障/忙...）并给排查建议。 从站"该响应但不响应/回了一帧看不懂"时用它。

  • nmea_parse

    解析 NMEA 0183 语句（GPS/北斗模块最常见的串口输出），给人话解读。

  • onewire_scan

    1-Wire 搜索 ROM，列出总线上每颗器件的 64 位 ROM 码，并解出家族码对应的器件。

  • parse_map

    解析 .map 文件：段占用（Flash/RAM）、符号表、可疑大符号（查大数组/大缓冲）。

  • peripheral_api_get

    单个驱动的外设初始化要求全文（取自其 *_port.h 适配层原注释）。 name 来自 peripheral_api_list。

  • peripheral_api_list

    外设 API 用法知识层：每个驱动要占哪些外设（I2C1/TIM1/UART2…）、 初始化顺序有什么硬要求。移植驱动或排查"外设配了但读不到数"时先查这里。

  • pin_check

    检查 MCU 引脚分配是否冲突（内置数据手册级复用映射）。 mcu 如 "stm32f103c8t6"；pins 如 {"PA9": "USART1_TX", "PB6": "I2C1_SCL", "PA0": "GPIO"}。 board 可选开发板名（如 "bluepill"）：板载外设占用的引脚再挪用会警告。 能抓：该脚没有此功能（AI 幻觉接线）、同一功能双占、SWD 脚挪用、 remap 档不匹配、非 5V 容忍脚；ESP32 类查硬约束（flash 保留脚/仅输入/strapping）。 写代码分配引脚之前必须先过一遍。

  • pinmap_get

    输出指定 MCU 的 pinmap JSON 原文（全引脚复用映射 + caveats + 常见冲突提示）。 pin_check 报错后想看完整数据、或需要给用户展示映射依据时用。

  • pinmap_list

    列出引脚知识库已收录的 MCU 型号。pin_check 前可用它确认型号是否支持。

  • probe_list

    探测已连接的调试器（DAPLink/ST-Link/J-Link...）和目标芯片。 "烧录失败/找不到目标芯片"时先调这个。需要可选依赖 pyocd。

  • project_detect

    识别一个**工程目录**属于哪个生态（扫标志文件：platformio.ini / *.uvprojx / prj.conf / SConstruct / *.ewp / Cargo.toml），并给出该生态的构建方式与常见坑。 拿到别人的工程压缩包、或不知道从哪下手时先跑这个。只探一层，不递归。

  • report_session

    把一次串口会话导出成 **Markdown 交付报告**（故障分析 + 原始日志附后）。

  • reset_reason

    读复位原因（RCC_RSR 标志）与内核运行状态，走 hotplug：**不复位、不停内核**。

  • rs485_sendwrite action

    经桥的 RS485 收发器发送字节（桥负责 DE 方向脚的时序）。

  • rtt_read

    通过 pyocd 的 RTT 通道读目标板调试日志（⚠ 实验性）。 固件需集成 SEGGER RTT 控制块；比 UART 快且不占串口外设。 cbuffer：控制块编号（多通道时指定，默认读全部）；probe_serial：多调试器时指定。 失败自动给排查指引，建议先 probe_list 确认调试器。

  • serial_close

    关闭串口句柄。调试结束记得关，释放端口。

  • serial_list

    列出系统可用串口。识别 CH340/CP2102/FT232 等常见 USB 转串口芯片并给驱动建议。 毕设学生"串口列表里找不到板子"时先调这个。

  • serial_open

    打开串口，返回句柄 handle。port 形如 "COM3" 或 "/dev/ttyUSB0"。 波特率不确定就先用 115200（STM32 HAL 默认）或 9600（老例程/模块默认）。

  • serial_pair_record

    同时监听两个串口，输出时间线交错的录制日志（RS485 主从对话/两设备联调）。 每行前缀 [A]/[B] 标明来源口，附 HEX 视图防波特率猜错时完全看不懂。最长 120s。

  • serial_read

    从串口读取数据（非阻塞，三条件提前退出）。 expect：正则，命中立即返回（如 expect="OK|ERROR" 等响应）； idle_ms：静默超时（板子说完就走）； seconds：总时长上限。返回文本视图 + HEX 视图 + 是否命中。 读到的内容同时累积进会话日志。

  • serial_sendwrite action

    向串口发送数据并等响应。newline=True 自动追加 \r\ （AT 指令必须！）。 expect：正则，如 "OK"——发 AT 后等到 OK/ERROR 立即返回，不傻等； wait_s：等待响应上限秒数（默认 0.5，AT 慢响应建议 3~5）。 hex_mode=True 时 data 按 HEX 解析（RS485/Modbus 用）。

  • serial_session_log

    取该句柄自打开以来的全部累积日志（喂给 analyze_log 做整体分析用）。

  • sessions_get

    读取指定会话日志的内容（文件名来自 sessions_list）。 默认显示尾部 200 行（日志开头常是复位前旧数据）。整段内容可直接喂 analyze_log。

  • sessions_list

    列出已落盘的串口会话日志（serial_open 时自动创建，新→旧）。 会话被关闭甚至对话轮次已隔很久之后，仍可用它找回之前的串口现场。

  • spi_read_reg

    发一个 SPI 命令字并读回 N 字节（对读了命令字的从设备通用）。

  • spi_scan

    逐条 CS 读 JEDEC ID（0x9F），找出板上挂的 SPI flash，并解出厂商与容量。

  • stack_unwind

    栈回溯：把 fault 时压栈的 8 个字还原成调用链，定位出错函数。

  • stream_capture

    长时录测：持续采集串口一段时间，逐行打上到达时间戳落盘。

  • symbol_lookup

    把地址反查成「函数名+偏移」。fault 地址定位代码的关键一步。

  • timing_analysis

    时序 / 数据率分析：找丢帧（序号跳号）、卡顿（间隔离群）、节拍漂移。

  • toolchain_status

    探测**本机**嵌入式工具链：编译器（ARM GCC / armclang / RISC-V / Xtensa）、 调试器、构建系统（CMake/Ninja/west/SCons/PlatformIO/Cargo）各给版本。 换机器、或「我这能编过、换台电脑就编不过」时先看这个。烧录器用 flash_tool_detect。

Public scan report

scanner v0.1.10 · 2026-10-24 · same rubric, same numbers if you re-run it

no findings
  • Code scan39 source files scanned25/25
  • –Live reliabilityno gateway calls yet and no remote to proben/a
  • –Tool poisoningtools not inspected (local package is not executed); not countedn/a
  • Auth qualitylocal package, no credentials required12/15
  • Maintenancelast push 1 days ago15/15
  • Maintainer identityregistry namespace matches repository owner7/10
Overall 91/100. Components that don't apply are left out of the denominator. Any critical finding is an F.RubricAppeal a findingJSON

How mcu-debug-mcp compares

Against every graded MCP server, from our own scans and uptime checks. Updated after each scan run.

Safety score
91/100
higher than 85% of 48,255 servers
Tools
59
the typical server has 7
Tools that change things
5%
typical: 0%. Fewer write tools means less an agent can break
Downloads a week
169
more than 72% of 12,191 servers with a package

What its tools let an agent do: 56 read · 3 change

Install mcu-debug-mcp in Claude Code, Cursor or VS Code

claude mcp add mcu-debug-mcp -- uvx mcu-debug-mcp
Add to Cursor

What the publisher says

From the mcu-debug-mcp repository's README, as published. We do not edit it. Read it on GitHub

mcu-debug-mcp · 嵌入式调试 MCP（领域级）

<!-- MCP Registry ownership: mcp-name: io.github.stillsurge/mcu-debug-mcp -->

让 AI"看到并看懂"你手上的板子：串口读写 + 故障模式库（45 条规则）+ 烧录失败模式直译 + Modbus 帧解析 + 编译报错解析 + 引脚冲突检测（三引擎）+ 板级知识库 + 波特率自动探测 + AT 序列回归 + 双口对录 + 会话持久化 + RTT 通道 + 烧录桥接 + 寄存器位域解码 + 调试器探测 + 预验证驱动模板库（9 款）+ 器件选型库（按接口/地址/时序要求） + 外设 API 用法层（初始化顺序硬要求） + 错误码统一查询（6 张表·带出处） + 报文解析（自定义二进制帧 / NMEA-GPS） + 工程结构与工具链探测 + 会话日志治理与交付报告。共 59 个工具 + 16 个 MCP resources + 6 个 prompts（8 静态 resources + 8 模板 resources）。

和"直接问 AI"的本质区别：AI 不再听你转述"传感器好像不太对"，而是亲自读到串口里的真实字节——AT 指令返回了什么、数据是全 0 还是乱码、程序是不是在反复重启、Keil 为什么烧不进去——然后按出厂预置的故障模式库给出诊断和排查步骤。引脚分配前用数据手册级映射表核对（能抓 AI 幻觉接线）。驱动代码来自验证过的模板库（纯函数 PC 可测 + Python 交叉验证），不是 AI 现编的。

安全与隔离：默认不碰硬件

这个 MCP 的工具会真的打开串口、写字节、烧 flash。开发机上常年挂着正在使用的设备 （UART 桥、调试器 CDC 口、正在跑的调试会话），一次误调用就能打断它们。所以默认档位是只读：

MCU_DEBUG_MCP_MODE=write              # 放开写权限（做真机操作时）
MCU_DEBUG_MCP_PORT_DENY=COM6,COM28    # 把在用的口锁死（即使放开了写权限也打不开）
MCU_DEBUG_MCP_NO_TOUCH_DTR=1          # 打开端口时不翻转 DTR/RTS，尽量不触发开发板自动复位

完整的风险矩阵（每个操作会做什么、需要什么才能执行、哪些操作没纳入闸门及原因）见 SECURITY.md。随时可用 env_status 查当前档位、名单与「因此被禁用了哪些操作」。

与同类工具的差异（2026-09 竞品调研结论）

同类串口 MCP（qarnet/serial-mcp、mcp-serial、uart-mcp 等）只做「串口通道」；本项目的差异化在知识层：

工具清单（59 个）

Shortened. The full README is on GitHub.

Nothing above is checked by us. What we check is on the safety report.

mcu-debug-mcp: common questions

Is mcu-debug-mcp server safe?
Yes, by our scan: it is graded A (91/100). Read the mcu-debug-mcp safety report
How do I install mcu-debug-mcp?
It runs on your machine. Copy the Claude Code, Cursor, VS Code or Claude Desktop config from the install section.
Does mcu-debug-mcp need an API key?
No secret keys are declared. It reads 2 settings from the environment.
Is mcu-debug-mcp maintained?
The last commit was 12 days ago (2026-10-23). The latest release is v0.1.1.
How does mcu-debug-mcp compare with other MCP servers?
safety score 91/100 (higher than 85% of 48,255 servers); tools 59 (the typical server has 7); tools that change things 5% (typical: 0%. Fewer write tools means less an agent can break). Full comparison.