Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
CODELLDB_PATHNoPath to an existing CodeLLDB installation (required on macOS or Windows, as the published npm bundle only ships Linux x64 CodeLLDB runtime)
SKIP_ADAPTER_VENDORNoSet to 'true' in CI environments to skip vendoring debug adapters during installation

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
{}
prompts
{}
resources
{
  "subscribe": true,
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
create_debug_sessionA

Create a new debugging session. Passing port, processId or an adapterConfig that names a target (a debugger URI: vmServiceUri, websocketAddress, vmServiceInfoFile; or a Flutter deviceId, for an app running on an Android device) attaches to a running process in the same call, with every attach argument attach_to_process takes (host alone does not); omit them for launch mode. Attaching pauses the target unless stopOnEntry is false

list_supported_languagesA

List all supported debugging languages with metadata

list_debug_sessionsA

List all active debugging sessions. Paused sessions include lastStop with the reason for the most recent stop (e.g. "breakpoint" vs "exception")

set_breakpointC

Set a breakpoint. Setting breakpoints on non-executable lines (structural, declarative) may lead to unexpected behavior

list_breakpointsA

List all breakpoints in a session with their verified state and adapter-assigned ids. Session-global function breakpoints appear separately as functionBreakpoints (omitted when filtering by file). Works before launch (queued, verified=false), while running or paused, and after the program exits

remove_breakpointA

Remove a breakpoint by breakpointId (returned by set_breakpoint / list_breakpoints), by function name, or by file + line (removes all breakpoints at that location). Takes effect immediately while the program is running or paused; also works after the program exits, before a relaunch

clear_breakpointsA

Remove all breakpoints in a session, or all breakpoints in one file. Clearing zero breakpoints is success. Takes effect immediately while the program is running or paused

start_debuggingA

Start debugging a script. Answers when the launched program stops, when it ends, or after a short hold — whichever comes first, and the same way in every language: "paused" with a reason and, as wait_for_stop answers a stop, the location, its source context and a note (a breakpoint reached as the program starts is answered here), "stopped" with the exit code, or "running" with pending:true when the program has not stopped yet; the message says what is armed. The hold is not a limit on the program — nothing is cancelled when it passes and breakpoints stay armed: call wait_for_stop to block until the program stops or ends (for a server, after sending the request that reaches your breakpoint). A stopOnEntry launch is answered at its entry stop

restart_debuggingA

Restart the debuggee: terminate the current program (if still running) and relaunch it with the same configuration as the last start_debugging. All current breakpoints are re-applied automatically. The get_output buffer starts fresh — read from since=0 after a restart. Works while running, paused, or after the program has exited. Not available for attach sessions or sessions never launched. Answers like start_debugging, including "running" with pending:true when the relaunch has not stopped within the same short hold (then call wait_for_stop)

attach_to_processA

Attach to a running process for debugging. After the handshake the target is verified by polling for threads; if none are reported within verifyTimeout (~20s default) the attach fails and the proxy is torn down. When a requested post-attach pause is accepted but no stopped event arrives within its bounded wait, returns state "running" with pending:true; the late event alone changes the session to "paused" — call wait_for_stop to block until it does

detach_from_processA

Detach from the debugged process without terminating it

expose_sessionA

Expose a debug session as a read-only DAP mirror endpoint on 127.0.0.1 so an IDE (e.g. VS Code) can attach as a second debug client and inspect live state: threads, stack, scopes, variables, evaluate. Returns host, port, and a session token the IDE must include as "mirrorToken" in its attach configuration. The mirror never drives execution — continue/step/pause and breakpoint changes are rejected; control stays with this MCP session. Requires an active session (launched or attached); works while running or paused. Calling it again returns the same endpoint. The endpoint closes on unexpose_session, close_debug_session, restart, or debuggee exit

unexpose_sessionA

Close a session's DAP mirror endpoint and disconnect any attached IDE clients. Succeeds as a no-op if the session is not exposed

close_debug_sessionC

Close a debugging session

step_overA

Step over the current line. Waits briefly for the program to stop; if the step is still executing after ~5s (e.g. stepping over a long-running call), returns success with state "running" and pending:true — the step is still in effect and the session becomes "paused" when it completes (call wait_for_stop to block until then, or pause_execution to interrupt)

step_intoA

Step into the current call. Waits briefly for the program to stop; if the step is still executing after ~5s, returns success with state "running" and pending:true — the session becomes "paused" when the step completes (call wait_for_stop to block until then)

step_outA

Step out of the current function. Waits briefly for the program to stop; if the step is still executing after ~5s (e.g. the rest of the function is long-running), returns success with state "running" and pending:true — the session becomes "paused" when the step completes (call wait_for_stop to block until then)

continue_executionA

Continue execution. Returns immediately after the adapter acknowledges; does not wait for the next stop. Call wait_for_stop to block until the program stops again or ends — it reports why (lastStop, e.g. "breakpoint" vs "exception") and where; list_debug_sessions and get_stack_trace show the same without waiting. Use get_output to read the program's stdout/stderr

wait_for_stopA

Block until the session next pauses or ends, then say why and where. Call it after continue_execution (which does not wait) and whenever a tool answers pending:true, instead of polling list_debug_sessions. Answers at once when the session is already paused (state "paused" with lastStop — the same record list_debug_sessions shows — and the top frame as location) or already over (the terminal state, with exitCode when the debuggee reported one); note says when the answer is anchored on a thread other than the one the stop was reported on, or when no frame of the shown stack is program code. If neither happens within the timeout it answers state "running" with pending:true: nothing was cancelled, breakpoints and exception filters stay armed — call it again to keep waiting, or pause_execution to interrupt

pause_executionA

Pause a running program. Waits briefly for the stop; if the program cannot stop within ~5s (e.g. blocked in native code, or an idle server waiting for input), returns success with pending:true and the session reports "paused" the next time the program runs code (call wait_for_stop to block until then). An observed stop answers with stopReason, the first visible frame as location (with its source context), and note when the stop was reported on a thread with no program frame — a sibling thread in program code is shown instead, or, when none has one, the note says no program frame is active. Fails with an actionable error if the session has no debuggable target to pause (e.g. a js attach whose target session was never adopted or has ended)

list_threadsB

List all threads in the debugged process

get_variablesA

Get variables (scope is variablesReference: number). Responses are size-guarded: oversized values are cut (truncated:true) and very large scopes return a capped list with a truncation notice — pass names:[...] to fetch specific variables in full

get_local_variablesA

Get local variables for the shared inspection anchor. If the stopped thread is frameless, a sibling with policy-recognized user frames is preferred, adopted, and disclosed in note. At a breakpoint or step inside a frame the stack display hides as internal (a node_modules dependency), the anchor is that frame — the one the program stopped in — and note says so. A JavaScript frame with no Local/block scope returns empty with guidance instead of mislabeling Global bindings. Responses are size-guarded; pass names:[...] to fetch specific variables in full

get_stack_traceB

Get stack trace. The response includes stopReason — why the session is paused. For an implicit frameless stopped thread, a sibling with policy-recognized user frames is preferred and adopted, with the switch disclosed in note. Internal/runtime frames are filtered by default; when any are hidden the response carries hiddenFrames and a note. When the frame the program is paused in is itself internal, pausedFrame names it (kept: whether it was retained as stackFrames[0]) and the note says so. The note also says when the top frame's file is newer than the compiled file the debugger binds it through (a stale build)

get_scopesC

Get scopes for a stack frame

evaluate_expressionA

Evaluate expression in the current debug context. Without frameId, uses the same adopted top frame as stack and locals — at a breakpoint or step that is the frame the program stopped in even when the stack display would hide it — and discloses an automatic thread switch or a hidden paused frame in anchorNote; frame names the frame that was used, on success and on failure. Expressions can read and modify program state. Waits up to 30s by default

get_source_contextB

Get source context around a specific line in a file

get_outputA

Get debuggee output (stdout/stderr/console) captured for a session. Buffered per launch (last 1000 entries; adapter telemetry and known adapter-internal diagnostics — e.g. LLDB DWARF-parser noise — filtered out). Works while the program is running and after it finishes, until the session is closed. Pass since=nextSince from the previous response to fetch only new output

hot_reloadA

Apply changed code to the running program and keep its state — the adapter's own live update. Flutter: the SDK adapter's hot reload (the app must have started; the reassemble runs build(), so a breakpoint there is reported by this call as the stop, with its location and snapshot; widget state, counters and timers survive; a reload sent to a paused program lands when it resumes). Java: class redefinition (JDI HotSwap) — scans classesDir for .class files modified after sinceTimestamp, redefines the ones the JVM has loaded, re-plants breakpoints, and returns which classes were redefined and the newest file timestamp (pass it as sinceTimestamp next time for an incremental update). Statement-anchored breakpoints are re-resolved against the new source after the update (anchorResolution reports moved/stale). Refused by name on the other languages. redefine_classes is a deprecated alias of this tool.

Prompts

Interactive templates invoked by user choice

NameDescription
debugging-workflowHow to debug effectively with mcp-debugger: session golden path, root-cause discipline, attach/remote recipes, and per-language quirks.

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.5/5.0

Scored across 29 tools

Disambiguation4/5

Most tools map to a distinct DAP operation (set/remove/clear breakpoints, step_over/into/out, pause vs continue vs wait_for_stop), and the descriptions actively clarify the run-state distinctions. The main overlaps are create_debug_session (which accepts every attach_to_process argument) versus attach_to_process, and get_variables versus get_local_variables, both of which an agent could plausibly misselect.

Naming Consistency5/5

All 29 names are snake_case with a verb-first or clear noun-object pattern (list_threads, set_breakpoint, start_debugging, wait_for_stop), with the only mild deviation being the domain term hot_reload. The expose/unexpose_session pair is internally symmetric, so the convention holds throughout.

Tool Count3/5

At 29 tools the surface is heavy, exceeding the comfortable range, though a full DAP debugger genuinely spans sessions, breakpoints, stepping, inspection, output, and hot reload. Some tools (expose_session/unexpose_session, hot_reload, list_supported_languages) are niche relative to the core debugging loop, pushing the set past what most agent sessions need.

Completeness4/5

Coverage is strong: session lifecycle (create/close/restart/detach), breakpoint CRUD plus clear, full stepping and pause/continue/wait, stack/scopes/variables/evaluate inspection, output streaming, source context, and hot reload. Gaps remain around exception-breakpoint configuration, conditional/watch (data) breakpoints, and explicit frame/thread selection or variable mutation outside evaluate_expression.

Maintenance

ActivityActive
ResponsivenessSyncing