dbgprobe-mcp-server
Related Servers
Alternatives to dbgprobe-mcp-server
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityDmaintenanceAn MCP server that provides comprehensive debugging capabilities for J-Link debuggers, enabling memory, flash, register, and RTT operations through AI assistants.34MIT
- AlicenseNot gradedqualityCmaintenanceAn MCP server that lets AI coding agents drive the full STM32 development loop—code generation, build, flash, debug, serial monitoring, and fault diagnosis—end to end via CubeIDE, CubeMX, CubeProgrammer, OpenOCD, and GDB.1MIT
- AlicenseCqualityAmaintenanceMCP server for AI-assisted MCU and embedded firmware debugging. It connects to real hardware via debug probes, inspects CPU/memory/peripherals, manages Keil builds, and provides structured evidence for fault diagnosis.196MIT
- AlicenseAqualityCmaintenanceMCP server for debugging STM32 microcontrollers over ST-LINK using STM32CubeCLT tools (GDB, ST-LINK_gdbserver, STM32_Programmer_CLI) with session management, flashing, breakpoints, memory/register access, and expression evaluation.191GPL 3.0
- AlicenseAqualityDmaintenanceDebug microcontrollers directly from Claude. This is an MCP server that drives OpenOCD, letting Claude flash firmware, control execution, and inspect a running target — and read your variables and peripheral registers by name instead of raw addresses.3924 PyPI4MIT
- AlicenseNot gradedqualityAmaintenanceMCP server for Agentic Hardware-in-the-Loop testing, enabling AI agents to probe, flash, reset, and validate embedded firmware on real hardware via bounded MCP tools.550 PyPI15Apache 2.0
TDQS
Scored across 41 tools
Each tool targets a distinct operation (e.g., breakpoint.set vs breakpoint.clear, mem.read vs mem.write) with no overlap. Even within categories like SVD, separate tools for reading, writing, describing, and listing ensure clear boundaries.
All tools follow a consistent hierarchical pattern: 'dbgprobe.<category>.<action>' (e.g., dbgprobe.breakpoint.set, dbgprobe.elf.attach). The naming is uniform and predictable across all 41 tools.
With 41 tools, the set is large but justified by the diverse domain (breakpoints, memory, ELF, SVD, RTT, tracing, plugins). Each tool serves a specific purpose, though a few categories (e.g., SVD with 8 tools) might be slightly over-partitioned.
The tool surface covers the full lifecycle of debug probe interaction: connection management, breakpoints, memory access, flash operations, ELF/SVD integration, RTT, tracing, and plugin extensibility. No obvious gaps hinder typical debugging workflows.