MCP Debugger
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CODELLDB_PATH | No | Path to an existing CodeLLDB installation (required on macOS or Windows, as the published npm bundle only ships Linux x64 CodeLLDB runtime) | |
| SKIP_ADAPTER_VENDOR | No | Set 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
| Capability | Details |
|---|---|
| tools | {} |
| prompts | {} |
| resources | {
"subscribe": true,
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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
| Name | Description |
|---|---|
| debugging-workflow | How 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
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 28 tools
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.
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.
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.
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.