The design leans on the model knowing debugger syntax already: rather than wrapping every breakpoint and backtrace as its own tool, it exposes a command channel per debugger and lets the assistant drive GDB or LLDB the way a person would at the prompt. The unified layer means you do not have to care which debugger is installed — debugger_start picks whichever is available and hands you a session.
A multi-debugger server for both GDB and LLDB: a unified session interface plus debugger-specific tools, so an AI assistant can start a session, issue arbitrary debugger commands, and track multiple sessions.
- A unified layer that auto-detects the debugger: debugger_status shows which debuggers are available, debugger_start begins a session with the detected one, debugger_command runs a command in it, and debugger_list_sessions and debugger_terminate manage the rest
- GDB directly: gdb_start (with an optional gdb_path), gdb_command to execute any GDB command, gdb_list_sessions and gdb_terminate
- LLDB directly: lldb_start, lldb_command for an arbitrary LLDB command, lldb_list_sessions and lldb_terminate
- The *_command tools are the escape hatch for everything else — the assistant already knows GDB and LLDB syntax, so any advanced debugger operation goes through them rather than a dedicated tool per feature
- Multiple concurrent sessions, each addressed by a session_id
Python and the uv package manager; set it up with uv sync and run server.py. It needs the mcp and pygdbmi packages. LLDB support wants LLVM installed (on macOS, brew install llvm python3), and GDB support wants GDB on the system — debugger_status reports which of the two is actually available.