Atlas / MCP servers / 0xmortuex / gdbstub-mcp

gdbstub-mcpSAFE

mcp/0xmortuex/gdbstub-mcp

MCP server that lets AI agents debug kernels through QEMU's gdbstub - no gdb binary. Breakpoints, registers, DWARF lines, backtraces, and triple-fault diagnosis.

Verdict
SAFE
Grade
B
Trust score
89 /100
Exposed tools
—
Transport
stdio
License
MIT
Stars
0
01

Overview

From the repository's own README, as read at the audited commit. Badges and raw HTML are left out.

Let your AI agent debug a kernel, and tell you why it triple-faulted.

gdbstub-mcp is an MCP server that gives AI agents (Claude Code, or any MCP client) a debugger for bare-metal code running in QEMU. It speaks the GDB Remote Serial Protocol directly to QEMU's built-in gdbstub, so you don't need a gdb binary. That matters most on Windows and macOS, where a cross-architecture gdb is a pain to get.

It's the companion to qemu-mcp. qemu-mcp lets an agent boot a kernel and see the crash. gdbstub-mcp lets it find out why.

What it looks like

An agent debugging a hobby kernel. This is real output, captured from the test kernel in tests/fixtures/kernel:

> debug_break kernel.c:10
#1 sw breakpoint at 0x100029  at kernel.c:10

> debug_continue
Stopped: SIGTRAP (breakpoint/step) - breakpoint #1 (kernel.c:10)
pc = 0x100029  at kernel.c:10
next: mov eax, dword ptr [ebp + 8]

> debug_backtrace
#0  0x100029  at kernel.c:10
#1  0x100071  at kernel.c:16
#2  0x1000b2  at kernel.c:28
#3  0x100016  at boot.s:21

> debug_registers eip,eflags,cr0
eip = 0x00100029   at kernel.c:10
eflags = 0x00000093  [SF AF CF]
cr0 = 0x00000011  [ET PE]

And when the machine silently reboots, debug_explain_fault reads QEMU's interrupt log and explains the crash:

> debug_explain_fault
A TRIPLE FAULT occurred: the CPU reset itself.

[0] #UD invalid opcode at triple_fault+0xa (kernel.c:23)
[1] #GP general protection fault at triple_fault+0xa (kernel.c:23)
selector 0x32: IDT entry 6 = #UD
-> the IDT entry for vector 0x6 is missing or invalid - the CPU couldn't
even start your handler. ...
[2] #DF double fault at triple_fault+0xa (kernel.c:23)

Root cause: the chain started with #UD at triple_fault+0xa.
It escalated to a triple fa
Read from source at commit 4fbc8fbce76bOBSERVED · 2026-10-11
02

Connect

Built from this server's own package name, version and transport as found in its source — not copied from anyone's documentation, so it cannot drift against a page we do not control.

claude-code (pypi)
claude mcp add gdbstub-mcp -- None gdbstub-mcp==0.1.0
03

Trust audit

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

LayerWhat it checksResult
L0Provenance & inventoryPASS
L1Static analysis of the codePASS
L2Instruction surface (what it tells the agent)PASS
L3Class-specific surfacePASS
L4Behavioural (sandbox)SKIPPED

What the source does

Filesystem
none-observed
Network
declared (2 observation(s))
Shell
none-observed
Dependencies
pinned
Secrets in source
none-found

Findings (7)

LOWInventory / provenance · inv.binary · CWE-1104
tests/fixtures/kernel/kernel.elf
kernel.elf
Why it matters. a compiled or binary member cannot be reviewed from source
Fix. ship source, or explain the binary in the README
LOWObfuscation / stealth · obf.decode_call · CWE-506, CWE-94
src/gdbstub_mcp/rsp.py:206
return bytes.fromhex(self.request("g").decode())
LOWObfuscation / stealth · obf.decode_call · CWE-506, CWE-94
src/gdbstub_mcp/rsp.py:209
return bytes.fromhex(self.request(f"p{regnum:x}").decode())
LOWObfuscation / stealth · obf.decode_call · CWE-506, CWE-94
src/gdbstub_mcp/rsp.py:224
out.extend(bytes.fromhex(reply.decode()))
LOWObfuscation / stealth · obf.decode_call · CWE-506, CWE-94
src/gdbstub_mcp/server.py:235
data = bytes.fromhex(hex_bytes.replace(" ", ""))
LOWObfuscation / stealth · obf.decode_call · CWE-506, CWE-94
tests/fake_stub.py:118
self.regs[int(n, 16)] = int.from_bytes(bytes.fromhex(v), "little")
LOWInventory / provenance · mcp.no_tools_extracted · CWE-1104
server.json
Why it matters. the tool list is enumerated at runtime by tools/list, not declared in source
Fix. the page says so rather than showing an empty table

Gates applied: no_behavioural_pass.

Audited 2026-10-11 · audit v0.4.1 · source sha 4fbc8fbce76bfull audit observations/trust-audit/mcp-server/0xmortuex__gdbstub-mcp.json · Report an issue / request a re-scan
04

Audit history

Every audit this server has had. A grade with a past is a grade somebody is still checking.

DateSourceVerdictGradeScoreChange
2026-10-114fbc8fbce76bSAFEB89first audit
05

Questions

What is the gdbstub-mcp MCP server?

MCP server that lets AI agents debug kernels through QEMU's gdbstub - no gdb binary. Breakpoints, registers, DWARF lines, backtraces, and triple-fault diagnosis.

Is gdbstub-mcp safe to connect to an agent?

The audit found nothing in the source that contradicts what it says it does, and graded it B (89/100). Grade A is held back for packages that have also passed a sandboxed behavioural run, which is why a clean server reads B.

What credentials does gdbstub-mcp need?

No credential environment variables were found in its source, so it appears to need none.

How does gdbstub-mcp run?

It speaks stdio, so it runs as a local process your client starts. It is published on PyPI as gdbstub-mcp.

How current is this page?

The grade is for one exact copy of the source (4fbc8fbce76b), read on 2026-10-11. The repository is watched and re-audited when it changes.

Advertisement