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.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
debug_sessionsA

Use this tool to list, create, or close isolated DAP sessions before routing other debugger tools with sessionId. Omit sessionId on normal debug tools only when the backward-compatible default session is intended; do not use a global session selector for concurrent work.

debug_compare_runsA

Compare bounded runtime evidence from two existing stopped DAP sessions. Use this for baseline or known-good versus candidate or failing differential debugging after both sessions have reached comparable stops. It compares stack identities, locals, registers, exception state, symbol health, and modules semantically; non-null raw address-only changes are marked unstable rather than causal evidence. Do not use it to launch, resume, or alter either target; prepare both runtime states with the normal lifecycle tools first.

debug_snapshotA

Capture bounded evidence from the current stopped debug state without resuming execution. Use this when an agent needs raw stack, locals, registers, exception details, modules, or nearby instructions; prefer debug_diagnose_stop when you also want ranked crash hypotheses and project-frame selection. This is read-only with respect to the debuggee and returns best-effort evidence plus collection errors for optional data that an adapter cannot provide.

debug_statusA

Inspect debugger lifecycle state, the selected stop, recent DAP events, and bounded adapter stderr without changing target execution. Use this to determine whether a session is initialized, running, stopped, postmortem, exited, or failed before choosing another debug tool; it is diagnostic only and does not resume, launch, attach, or terminate the debuggee.

debug_disconnectA

End the active DAP session and stop its local adapter process. Use this when debugging is finished or the session must be reset; do not call it when more runtime evidence is still needed. With terminateDebuggee=true it may also terminate a live target process, so this operation can destroy the current runtime state and cannot be treated as read-only.

debug_run_to_stopA

Run one live launch or attach through an already initialized DAP adapter until the first stopped, exited, or terminated event. Use this when you need deterministic runtime evidence from a reproduction; do not use it for a postmortem dump or when executing/attaching to the local target is not authorized. Launch mode executes application code and attach mode changes debugger control of an existing process, so normal target side effects may occur before the stop. Returns the request result, terminal/stopped outcome, session status, and a bounded snapshot only when a stopped event is captured.

debug_diagnose_stopA

Diagnose an already stopped live or postmortem debug session without changing execution state. Use this when a debugger has captured the failure and you want project-frame selection, crash classification, operand/register/variable bindings, call-chain provenance, ranked hypotheses, and a fix/rebuild/reproduce/verify plan; use debug_snapshot instead when only raw evidence is needed. The tool is read-only and returns both the bounded snapshot and the derived diagnosis, including collection limitations when optional debugger evidence is unavailable.

debug_source_disassemblyA

Correlate source locations, disassembly, registers, and pointer-like locals for the raw fault frame and the first likely project-controlled frame. Use this for low-level root-cause evidence when a crash is already stopped and instruction/operand provenance matters; prefer debug_diagnose_stop for a broader ranked diagnosis. This is read-only, does not resume the target, and returns frame-selection reasoning, both correlations, operand bindings, and any best-effort collection errors.

debug_this_crashA

Preferred high-level native crash workflow. Use mode=current for an already stopped session, dump for read-only postmortem analysis, codelldb to discover CodeLLDB, lldb-dap to discover upstream LLVM lldb-dap, gdb to discover GNU GDB built-in DAP interpreter, or live with an already initialized generic DAP adapter. Do not use codelldb/lldb-dap/gdb/live when executing or attaching to the target is not authorized: those modes can run application code and cause its normal side effects, while current/dump only inspect stopped evidence. workflow.stage selects initial diagnosis, verification against a prior baseline, or the bounded autonomous cycle. Returns runtime evidence, diagnosis, verification/autonomous metadata, and debugger status with deterministic fixed/blocked/budget-exhausted outcomes where applicable.

debug_causal_traceA

Build a bounded consumer-to-writer evidence chain for one suspicious debugger-visible value. Use it after crash or differential evidence identifies a value whose runtime producers matter. It combines the current stopped snapshot with repeated watchpoint writer tracing. Do not use it for frozen dumps or unsafe-to-resume targets, and do not treat an observed writer as automatic proof of root cause.

debug_progress_probeA

Sample a live target across short resume/pause intervals to distinguish no observed progress, same-frame execution movement, and probable busy loops. Use it when a process appears hung but a single thread snapshot cannot distinguish blocking from spinning. Do not use it when resuming the target is unsafe; sampling perturbs scheduling and is not proof of application-level progress.

debug_runtime_reportA

Create a shareable structured report from the current stopped target with normalized crash fingerprinting, Symbol Doctor status, sanitizer stderr correlation, poison-pattern memory hazard detection, ABI register-to-argument mapping, and recent debugger output. Use it only for evidence-driven triage and issue handoff. Do not treat heuristic poison patterns, ABI mappings, or sanitizer text correlation as standalone proof.

debug_trace_lifetimeA

Trace lifetime evidence for one debugger-visible pointer or object handle using the current snapshot, sanitizer/runtime output, bounded forward writer tracing, and optional reverse stepping when supported. Use this for suspected use-after-free, stale ownership, or unexpected pointer replacement. Do not use forward tracing on a frozen dump or when resuming the target is unsafe.

debug_adaptive_evidenceA

Collect runtime evidence in progressively richer bounded phases instead of immediately requesting a maximal snapshot. Use it when token/DAP cost matters or the amount of evidence needed is unknown: it starts with stack and small locals, expands only when symbols, exception state, or variables are insufficient, and finishes with a full runtime report when needed. Do not use it to replace deliberate deep inspection when the required evidence is already known.

debug_this_hangA

High-level native hang workflow for all-thread triage. Use it when a live process appears stuck, deadlocked, waiting forever, or spinning and you need bounded stacks from every thread, wait-state/deadlock heuristics, and cross-thread Pointer-Provenance v2. In current mode it inspects an existing configured session and pauses a running live target when necessary; codelldb, lldb-dap, gdb, and live modes can launch or attach to an authorized local target, observe it for a bounded interval, then pause it for evidence. Do not use executable/attach modes when target execution or debugger control is not authorized, and do not treat a deadlock-candidate as a proven lock cycle because generic DAP does not expose portable lock ownership.

debug_find_writerA

Temporarily watch a variable or debugger expression, resume an authorized live target, and capture the first resulting stop to identify the immediate writer candidate. Use this after a stopped-state diagnosis suggests a value was corrupted and runtime provenance is needed; do not use it for crash dumps or when resuming is unsafe. Adapters with DAP data-breakpoint support use that protocol directly; GDB 14/15 uses a bounded watch/rwatch/awatch command through DAP REPL because those releases do not advertise native data breakpoints. The tool removes only the temporary watch it created and never automatically continues through an unrelated stop.

debug_trace_valueA

Build a bounded temporal write timeline for one debugger-visible variable or expression. Use this after differential or crash evidence identifies a suspicious value and repeated live-target resume is safe. The tool installs one temporary data breakpoint or watchpoint at a time, resumes to the next confirmed writer, captures bounded runtime evidence, removes only its own temporary watch, and repeats. Do not use it for crash dumps, unsafe-to-resume targets, or as proof that an observed writer is the root cause; it stops on unrelated debugger events rather than continuing through them.

debug_open_dumpA

Open a local native core/minidump with CodeLLDB, upstream LLVM lldb-dap, or GNU GDB DAP and capture bounded postmortem evidence. Use this when the failure is already recorded and no target process should execute; use debug_run_to_stop or debug_this_crash for a live reproduction instead. The tool starts only the selected local debugger adapter, never launches or resumes the crashed program, treats the dump as read-only, and returns the initial stack/locals/registers plus optional modules and disassembly.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.1/5.0

Scored across 18 tools

Disambiguation3/5

Several tools cluster around the same activity: stopped-state evidence (snapshot, diagnose_stop, runtime_report, adaptive_evidence, source_disassembly) and writer tracing (find_writer, trace_value, causal_trace, trace_lifetime). The descriptions include explicit use-case guardrails and 'do not use' guidance, which helps, but an agent would need to read carefully to avoid picking the wrong tool.

Naming Consistency4/5

All tools share the debug_ prefix and use snake_case, with most following a verb_noun pattern like debug_run_to_stop, debug_open_dump, and debug_disconnect. A few exceptions such as debug_this_crash, debug_this_hang, and simple noun forms like debug_status and debug_sessions break the strict pattern, but the overall convention remains predictable.

Tool Count4/5

Eighteen tools is above the ideal 3-15 range, but the server covers a broad debugging domain including session lifecycle, crash/hang workflows, postmortem dumps, snapshotting, tracing, comparison, and reporting. The count feels slightly heavy rather than bloated, and each tool appears to have a distinct role.

Completeness4/5

The tool surface covers the core debug lifecycle: session management, launch/attach/run-to-stop, crash and hang triage, dump analysis, evidence capture, diagnosis, tracing, comparison, and disconnect. Minor gaps exist around explicit breakpoint management, stepping controls, and standalone expression evaluation, but those are outside the server's evident evidence-focused purpose.

Maintenance

ActivityMaintained
ResponsivenessResponsive