gdbstub-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Debug a running kernel through a GDB remote stub (QEMU's -s / -gdb tcp::PORT), with no gdb binary needed. Start QEMU with -s -S (stub on 1234, CPU halted), then: debug_connect (pass elf= for symbols) -> debug_break on a symbol or file:line -> debug_continue -> debug_registers / debug_backtrace / debug_memory. For a crash or reboot loop, run QEMU with -d int,cpu_reset -D <log> and call debug_explain_fault on the log: it decodes the exception chain that led to a triple fault. Addresses accept 0x1234, symbol, symbol+0x10, file.c:42 or $reg.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| debug_connectA | Connect to a gdbstub and register the session under For QEMU, start it with |
| debug_disconnectA | Remove breakpoints, detach from the stub so the guest keeps running, and forget the session. A running target is halted first. |
| debug_sessionsB | List active debug sessions. |
| debug_registersA | Read registers. Target must be halted. registers is a comma-separated list (e.g. "eip,esp,cr2,cr3"); default is
the general set from the stub's |
| debug_set_registerC | Write a register. value is an address expression (0x10, symbol, ...). |
| debug_memoryA | Read guest memory (virtual addresses, as the CPU currently sees them). address accepts 0x1234, symbol, symbol+0x10, file.c:42 or $esp+8. format: "hex" (hexdump with ASCII), "words" (pointer-sized words, symbolized), or "string" (NUL-terminated string at address). length is capped at 4096 bytes. |
| debug_write_memoryC | Write raw bytes (hex string, e.g. "90 90 cc") to guest memory. |
| debug_breakA | Set a breakpoint or watchpoint. location: 0x1234, symbol, symbol+0x10, or file.c:42. kind: "sw" (software breakpoint), "hw" (hardware breakpoint - use this before paging is enabled or for code that isn't loaded yet), or a watchpoint: "write", "read", "access" (length bytes, default one word). |
| debug_deleteC | Remove a breakpoint/watchpoint by its # id. |
| debug_breakpointsC | List breakpoints and watchpoints. |
| debug_continueA | Resume the target and wait up to timeout_s for it to stop. If it hasn't stopped by then it keeps running: call debug_wait to keep waiting, or debug_interrupt to halt it where it is. |
| debug_waitB | Wait for a running target to stop (after debug_continue timed out). |
| debug_interruptB | Halt a running target immediately (like Ctrl-C in gdb). |
| debug_stepB | Single-step |
| debug_backtraceB | Show the call stack. mode "fp" walks the frame-pointer chain (exact, but only if the kernel was built with frame pointers, e.g. -fno-omit-frame-pointer); "scan" scans the stack for return addresses (works on -O2 kernels without frame pointers, x86 only, needs elf; may include stale frames); "auto" tries fp and falls back to scan if the chain is empty. |
| debug_disassembleB | Disassemble bits overrides the decode mode on x86 (16 for real mode, 32, 64) - useful in bootloader code that runs before the CPU mode matches the ELF. |
| debug_symbolA | Look up symbols without touching the target. query: an address (0x100abc) -> symbol+offset and source line; a symbol or symbol+off -> its address, size and source line; or file.c:42 -> address. Uses the session's ELF (name=) or a standalone ELF path (elf=). |
| debug_explain_faultA | Explain a crash / triple fault from a QEMU interrupt log. Produce the log by running QEMU with |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 18 tools
Most tools target clearly distinct operations: break vs delete vs breakpoints, continue vs wait vs interrupt, and registers vs memory are all well separated by their descriptions. Minor confusion risks remain: debug_delete's name doesn't indicate it only removes breakpoints (as opposed to disconnecting a session), and the read/write asymmetry of debug_registers vs debug_set_register could momentarily puzzle an agent.
All tools share the debug_ prefix, but the suffixes mix conventions: verb_noun tools (debug_connect, debug_set_register, debug_write_memory) coexist with bare-noun read/list tools (debug_registers, debug_memory, debug_sessions, debug_breakpoints). The set is readable and predictable enough to navigate, but not a uniform pattern.
18 tools is on the high side but justified for a debugger surface spanning connection, registers, memory, breakpoints, execution control, stack/symbol inspection, and fault analysis. Each tool maps to a real gdb operation; none appear obviously redundant.
The surface covers the full debugger lifecycle: connect/disconnect, session listing, register and memory read/write, breakpoint/watchpoint create/list/delete, continue/wait/interrupt/step execution control, disassembly, backtrace, symbol lookup, and fault explanation. No obvious dead ends for the stated purpose.