Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
debug_connectA

Connect to a gdbstub and register the session under name.

For QEMU, start it with -s (stub on tcp::1234) or -gdb tcp::PORT, and add -S to halt the CPU before the first instruction so you can set breakpoints before anything runs. With qemu-mcp, pass these via qemu_boot's extra_args, e.g. extra_args="-s -S". elf is the kernel image with symbols (and ideally DWARF debug info); it enables symbol names, file:line breakpoints and source locations. load_bias is added to every ELF address, for images loaded somewhere other than their link address (0 for a normally linked kernel). The target stays halted after connecting.

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 g packet. all=True also reads every extra register the target describes (control registers, segment bases, FPU/SSE...). Flag registers (eflags, cr0, cr4...) are decoded.

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 count machine instructions (1..1000) and show where it stopped.

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 count instructions from address (default: current pc).

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 -d int,cpu_reset -D <log_path> (add -no-reboot so a triple fault stops the VM instead of looping). Decodes the exception chain (vector names, page-fault and selector error codes, CR2), filters out timer IRQs and software interrupts, points at the root cause, and symbolizes addresses when elf is given. x86 only.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

B3.4/5.0

Scored across 18 tools

Disambiguation4/5

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.

Naming Consistency3/5

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.

Tool Count4/5

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.

Completeness5/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo recent community issues