debugger_statusLABSCO SUMMARY
One interface over two debuggers, thin by design.
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.
What it is
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.
What you get
- 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
Requirements
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.
Setup effort
Build from source
USE CASES
01
Debugging a crash without leaving the assistant
Check which debugger is available, start a session on the binary, and drive it with debugger commands — setting breakpoints, running, and reading the backtrace through the command channel.
02
Using a specific debugger
Start GDB or LLDB directly when you need that one in particular, and issue its native commands for the session.
03
Juggling several debugging sessions
List the active sessions, work each by its id, and terminate the ones you are done with to free resources.
13 tools
Listed in project docs. Your client may show a different list.
debugger_startdebugger_terminatedebugger_list_sessionsdebugger_commandlldb_startlldb_terminatelldb_list_sessionslldb_commandgdb_startgdb_terminategdb_list_sessionsgdb_commandBEFORE YOU INSTALL
What to know first
Tools you get
13 tools named in the project's documentation.
Where it runs
The documented client runs the server on your machine.
INSTALLATION
Connect your client
You clone and build this one yourself.
Server setup
TERMINAL
git clone https://github.com/smadi0x86/MDB-MCP
cd MDB-MCP
uv sync
uv venv
uv run server.pyMCP Clients
Any MCP client
ANY MCP CLIENT · JSON
{
"mcpServers": {
"gdb": {
"command": "uv",
"args": [
"run",
"<YOUR_PATH_TO_MDB_MCP>/server.py"
],
"disabled": false
}
}
}
