smadi0x86/MDB-MCP

An MCP server that gives your AI assistant a real debugger. It drives GDB or LLDB,
so the assistant can set breakpoints, run your program, read memory and walk the
stack the same way you would.
## Install
You need uv and at least one debugger:
bash
# Debian / Ubuntu
sudo apt install gdb lldb python3-lldb
# macOS (LLDB ships with the Xcode command line tools)
xcode-select --install
Then add the server to your client. For Claude Code:
bash
claude mcp add mdb -- uvx --from git+https://github.com/smadi0x86/MDB-MCP mdb-mcp
For Claude Desktop, Cursor or Windsurf:
json
"mcpServers": {
"mdb": {
"command": "uvx",
"args": ["--from", "git+https://github.com/smadi0x86/MDB-MCP", "mdb-mcp"]
VS Code takes the same entry under "servers" in .vscode/mcp.json, with
"type": "stdio" added. On Windows with WSL, set "command": "wsl" and put the full
path to uvx at the start of args.
## Tools
debuggerstatus which debuggers are usable, and the open sessions
debuggerstart start a gdb or lldb session, optionally loading a program
debuggercommand run any gdb or lldb command
debuggerinterrupt pause a running program, like Ctrl-C
debuggerterminate kill the program and close the session
Everything else is a normal debugger command, so break main, bt, x/16gx $sp
and frame variable all work. Commands that resume the program wait for it to stop
(10 seconds by default, adjustable per call). If it is still running after that, the
assistant can interrupt it or keep waiting.
GDB is the default on Linux and LLDB on macOS. Either can be picked explicitly. GDB
loads your ~/.gdbinit, so pwndbg and GEF keep working.
## Try it
bash
make -C examples
Then ask your assistant why examples/crash segfaults (give it the absolute path).
## Configuration
To use a debugger other than the one on your PATH, set it in the server's env in
your client config:
json
"env": {
"MDBGDBPATH": "gdb-multiarch",
"MDBLLDBPATH": "/opt/homebrew/opt/llvm/bin/lldb"
## Troubleshooting
If LLDB shows up as unavailable, debuggerstatus tells you why. On Debian and
Ubuntu it is usually a missing python3-lldb, which has to match your LLDB version.
The program can't read from your keyboard. Feed it a file instead:
run < input.txt # gdb
process launch -i input.txt # lldb
If attaching to a running process fails on Linux, check
/proc/sys/kernel/yama/ptracescope. A value of 1 only allows debugging child