Server data from the Official MCP Registry
AI-native MCU debugging and observability through probes, symbols, RTOS, logs, and build tools.
AI-native MCU debugging and observability through probes, symbols, RTOS, logs, and build tools.
McuBuddy is a well-structured MCP server for embedded MCU debugging with appropriate authentication boundaries and reasonable permissions. However, there are several concerns: (1) the J-Link backend loads native DLLs from multiple hardcoded filesystem paths including user-controlled locations, creating a potential DLL hijacking vulnerability; (2) the server executes external processes (Keil UV4) without comprehensive input validation; (3) limited error handling and logging of sensitive operations like memory writes and Flash operations could mask security issues. Permissions align with the server's MCU debugging purpose, but the DLL loading mechanism and process execution patterns introduce moderate risk. Supply chain analysis found 3 known vulnerabilities in dependencies (0 critical, 3 high severity). Package verification found 1 issue.
4 files analyzed · 11 issues found
Security scores are indicators to help you make informed decisions, not guarantees. Always review permissions before connecting any MCP server.
This plugin requests these system permissions. Most are normal for its category.
Add this to your MCP configuration file:
{
"mcpServers": {
"io-github-cunjun-mcubuddy": {
"args": [
"McuBuddy"
],
"command": "uvx"
}
}
}From the project's GitHub README.
Let AI do more than analyze firmware code: connect to real MCUs, operate debugging tools, and collect board-level evidence.
McuBuddy is a Model Context Protocol (MCP) server for
MCU board-level debugging. It exposes debug probes, Keil MDK projects, ELF/DWARF symbols,
CPU and memory state, SVD peripheral registers, UART/RTT logs, FreeRTOS state, Flash operations,
and GDB servers as structured tools that AI assistants can call.
It is designed for firmware development, board bring-up, fault isolation, debugging automation, and AI-assisted validation.
[!IMPORTANT] This project is still in Alpha. Humans remain responsible for goals, wiring, and risk decisions; AI calls tools, organizes evidence, and advances the debugging process. Before resets, execution control, memory writes, or Flash operations, confirm the target, impact, and recovery plan.
Documentation: Quickstart · Tool Reference · Support Matrix · Architecture
.uvprojx / .uvproj files, select a target, invoke UV4
builds or downloads, and feed the generated AXF/ELF into the debugging workflow.flowchart LR
AI["AI Client<br/>Codex / Claude Code"] --> MCP["McuBuddy<br/>MCP Server"]
MCP --> EB["Execution Boundary<br/>Serialized Session"]
EB --> TOOLS["Debugging Tools<br/>Diagnostics / Symbols / SVD / RTOS / Logs"]
TOOLS --> KEIL["Keil UV4<br/>Build / Optional Download"]
TOOLS --> PROBE["Probe Backends<br/>pyOCD / J-Link / probe-rs"]
KEIL --> IMAGE["AXF / ELF / HEX / BIN"]
IMAGE --> TOOLS
PROBE --> BOARD["Real MCU Board"]
| Component | Responsibility |
|---|---|
| AI clients such as Codex and Claude Code | Understand the problem, select tools, interpret results, and propose the next checks |
| MCP | Standard tool-calling protocol between the AI client and McuBuddy |
McuBuddy | Manage debug sessions, invoke backends, enforce safety checks, and return structured results |
| Keil MDK / UV4 | Build and link Keil projects, with optional configured firmware download |
| pyOCD, J-Link, and experimental probe-rs | Connect to probes and access target registers, memory, breakpoints, and Flash |
| ELF/AXF, DWARF, and SVD | Provide symbols, source locations, variables, call stacks, and peripheral-register semantics |
MCP is not a protocol for invoking Keil. The AI calls McuBuddy through MCP; McuBuddy then
uses Keil UV4, pyOCD, J-Link, or another internal backend as required by the task.
Basic requirements:
Windows and an installed Keil MDK / UV4 are required only for Keil build or download features.
pip install McuBuddy
Install the optional dependency when using the J-Link Python backend:
pip install "McuBuddy[jlink]"
For development from source:
git clone https://github.com/cunjun/McuBuddy.git
cd McuBuddy
pip install -e ".[dev]"
{
"mcpServers": {
"McuBuddy": {
"command": "python",
"args": ["-m", "McuBuddy"]
}
}
}
For a Windows source checkout, explicitly configure the virtual-environment Python executable and working directory. See the Windows MCP Configuration Example, then restart the AI client.
After connecting the probe and powering the board, tell the AI:
Use McuBuddy to inspect the current debugging environment, discover connected probes,
and perform a first read-only check of the board without writing Flash.
Before starting, tell me what information is still missing.
The recommended sequence is to check the environment and target first, then configure the probe and read the minimum target state:
doctor()
list_connected_probes()
match_chip_name("py32f030x8")
configure_probe(target="py32f030x8", backend="pyocd")
board_smoke_test(disconnect_after=True)
board_smoke_test does not write Flash, but it may halt the target by default to capture a stable
context, so it is still execution-changing. If the device must not be halted, instruct the AI to
perform only non-intrusive probe and environment checks.
The following prompts can be given directly to an AI assistant connected to McuBuddy.
List the connected debug probes, confirm that the target chip matches, and perform a read-only
check of the board. Do not reset the target, write memory, or erase or program Flash.
If you identify a risk, stop and explain it first.
Halt the target and read PC, LR, SP, and the fault registers. Resolve the call stack using the
current AXF/ELF, identify the most likely source location of the HardFault, and list the evidence
that supports the conclusion.
Find the Keil project and targets under the project directory. First tell me which project,
target, and UV4.exe you plan to use. After confirmation, build the project and load the generated
AXF without downloading firmware, then use the probe to run to main.
Load an SVD that matches the target chip and inspect the RCC, GPIOA, and UART peripheral state.
Check whether the clock, pin multiplexing, and interrupt configuration are consistent, and explain
any abnormal fields.
Read the FreeRTOS task list, current task contexts, and stack usage. Identify blocked tasks,
abnormal states, or stack risks without modifying the target state.
For more evidence-driven prompts and decision sequences, see the AI Playbook and AI Examples.
| Category | Main Capabilities |
|---|---|
| Probes and targets | Probe discovery, target matching, connect/disconnect, halt/resume, reset, and stepping |
| CPU and memory | Core/FPU/fault registers, memory access, stopped context, Flash comparison, and verification |
| Breakpoints and execution | Hardware/software breakpoints, watchpoints, run-to-function/source, and Step Over/Out |
| Symbols and source | ELF/AXF, DWARF, disassembly, functions, variables, source mapping, and call stacks |
| Peripherals and RTOS | CMSIS-SVD, peripheral fields, FreeRTOS tasks, task contexts, and stack checks |
| Logs and services | UART, RTT, selected SWO, and pyOCD/J-Link GDB servers |
| Projects and diagnostics | Keil project discovery, build/download, HardFault, startup, clock, interrupt, and peripheral diagnosis |
For complete tool names, parameters, and return values, see the Tool Reference.
| Path | Current Role | Main Capabilities |
|---|---|---|
| pyOCD + ST-Link/CMSIS-DAP | Primary backend | Control, memory, Flash, source debugging, RTT, RTOS, and GDB server |
| J-Link | Primary backend | Control, memory, Flash, source debugging, native RTT, DWT, and GDB server |
| probe-rs sidecar | Experimental | Discovery, connection, core control, registers, memory, and hardware breakpoints |
| Keil UV4 (Windows) | Build/download backend | Project discovery, target configuration, build, logs, and optional download |
Primary validation coverage includes:
“Implemented in code” does not mean “validated on every board.” Use the
Support Matrix and list_validation_records() as the source of truth.
Keil provides project build, linking, and optional firmware download. McuBuddy does not replace
the Keil compiler or parse and rewrite project build rules. It discovers projects, selects targets,
invokes UV4, reads logs and output files, and feeds the results into automated debugging.
Discover the Keil project
→ Configure UV4, the target, and logs
→ Invoke the Keil build
→ Load the generated AXF/ELF
→ Connect through pyOCD/J-Link and diagnose the board
→ Download through Keil after user confirmation
→ Reconnect and verify Flash
discover_keil_projects(root=r"E:\work_code\app")
configure_keil_project(
project_path=r"E:\work_code\app\MDK-ARM\Project.uvprojx",
uv4_path=r"C:\Keil_v5\UV4\UV4.exe",
target_name="Debug",
)
The user or AI should review automatic discovery results. When a directory contains multiple
projects, targets, or output files, explicitly specify project_path, target_name, and elf_path.
build_project(timeout_seconds=120)
configure_elf(elf_path=r"E:\work_code\app\MDK-ARM\Objects\Project.axf")
elf_load(path=r"E:\work_code\app\MDK-ARM\Objects\Project.axf")
Once the AXF is loaded, the AI can reliably resolve PC, LR, and memory addresses to functions, source lines, local variables, and call stacks.
configure_probe(target="py32f030x8", backend="pyocd")
probe_connect(target="py32f030x8")
probe_halt()
read_stopped_context()
run_to_function("main")
If Keil, J-Link Commander, a GDB server, or another debugger already owns the probe, close that session first; otherwise pyOCD or J-Link may fail to connect.
flash_firmware invokes the configured Keil UV4 download flow and modifies target Flash, so it
requires explicit confirmation:
flash_firmware(timeout_seconds=120, confirm=True)
compare_elf_to_flash()
Before downloading, confirm the project, target, firmware output, chip model, and recovery plan. For the complete new-project workflow, see the Generic Board Workflow.
probe_halt()
read_stopped_context(include_fault_registers=True)
diagnose_hardfault()
backtrace()
svd_load(svd_path=r"C:\path\Device.svd")
svd_read_peripheral(peripheral="RCC")
svd_read_peripheral(peripheral="GPIOA")
diagnose_peripheral_stuck(peripheral="UART")
list_rtos_tasks()
rtos_task_context(task_name="WorkerTask")
read_stack_usage()
run_to_function("main")
run_to_source(file="main.c", line=120)
source_step()
step_over()
McuBuddy provides machine-readable safety classifications through list_tool_safety().
| Category | Examples | Default Requirement |
|---|---|---|
| Read-only | Target matching, register/memory reads, symbol resolution, logs, diagnostics | No confirmation required |
| Execution-changing | halt, resume, reset, continue, stepping | Does not write Flash, but changes execution state |
| Runtime-state write | Memory/register writes, breakpoints, watchpoints, SVD field writes | Explicit confirmation |
| Persistent destructive operation | Flash erase/program, Keil firmware download | Explicit confirmation |
| Host process | Keil build, GDB server start/stop | Starts or stops a local process |
Safety principles:
Session.This prevents one request from switching backends, disconnecting the probe, or changing shared state while another probe operation is still running.
The repository includes skills/mcubug, which guides Codex and Claude Code to use these tools in an
“evidence first, judgment second” sequence instead of treating MCP tools as an unordered command list.
Install for Codex:
python .\skills\mcubug\scripts\install_skill.py --target codex --overwrite
Install for Claude Code:
python .\skills\mcubug\scripts\install_skill.py --target cc --overwrite
Restart the client or open a new session after installation. See mcubug Skill for Codex and Claude Code for details.
pip install -e ".[dev]"
pytest
ruff check src tests
See the Docs Index for repository layout and documentation ownership.
This project is licensed under the MIT License. See LICENSE for details.
If McuBuddy helps with your MCU debugging workflow, consider giving the project a Star.
Be the first to review this server!
by Modelcontextprotocol · Developer Tools
Web content fetching and conversion for efficient LLM usage
by Toleno · Developer Tools
Toleno Network MCP Server — Manage your Toleno mining account with Claude AI using natural language.
by mcp-marketplace · Developer Tools
Create, build, and publish Python MCP servers to PyPI — conversationally.