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. Provide host and port to attach to a running process; 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_breakpointB

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_debuggingB

Start debugging a script. Answers with the session as it is after the program's first stop, its exit, or a readiness window: "paused" with a reason (a launch with breakpoints answers at the first one), "stopped" with the exit code, or "running" with pending:true when the program is still running — after ~5s when nothing is armed to stop it (no breakpoints, no entry stop, no caught-exception filter; the "uncaught" default does not count), after 30s when something is; the message says what was or was not reached. A later stop shows in list_debug_sessions as the state flips to "paused"

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 its readiness window

attach_to_processB

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"

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_overB

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 session becomes "paused" when the step completes (check list_debug_sessions, or call 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

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

continue_executionA

Continue execution. Returns immediately after the adapter acknowledges; does not wait for the next stop. When the program stops again the session state becomes "paused" — check list_debug_sessions or get_stack_trace, whose lastStop/stopReason tells you why it stopped (e.g. "breakpoint" vs "exception"). Use get_output to read the program's stdout/stderr

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. 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_traceA

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

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

redefine_classesA

Hot-swap changed Java classes into a running JVM. Scans a classes directory for .class files modified after sinceTimestamp, matches them against loaded classes in the target JVM, and redefines them using JDI. Returns which classes were redefined and the newest file timestamp (pass as sinceTimestamp on next call for incremental updates). Statement-anchored breakpoints are re-resolved against the new source after the swap (anchorResolution reports moved/stale). Only works with Java debug sessions.

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 28 tools

Disambiguation4/5

Most tools have clearly distinct purposes (e.g., step_over vs step_into vs continue_execution, get_scopes vs get_variables). However, create_debug_session, attach_to_process, and start_debugging overlap in session attachment/launch semantics, which could cause an agent to hesitate between them. Descriptions help but do not fully resolve the boundary.

Naming Consistency5/5

All 28 tools follow a consistent snake_case verb_noun pattern (e.g., set_breakpoint, list_breakpoints, get_stack_trace, close_debug_session). Even the few exceptions like step_over and step_into fit the same naming family. No mixed conventions or chaotic naming.

Tool Count3/5

28 tools is on the heavy side for an MCP server, and some features are convenience layers (get_local_variables) or advanced/niche (expose_session, redefine_classes). The debugger domain legitimately requires many operations, so it is borderline rather than clearly excessive, but a few tools could be merged or omitted.

Completeness4/5

The surface covers core debugger lifecycle: session management, breakpoints, stepping, inspection (variables, stack, scopes, threads), evaluation, output, and session teardown. Minor gaps exist (e.g., no explicit conditional breakpoint or logpoint update tool, no watch expression management), but agents can work around most of these.

Maintenance

ActivityActive
ResponsivenessWithin a week