Skip to main content
Glama
XC881

xcnodejs-debugger-mcp

by XC881

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_launchA

Spawn a Node program under --inspect-brk=127.0.0.1:0 and return a new sessionId in awaiting_start. cwd defaults to the package root of program (the directory that owns that file's node_modules). User code does not run until debug_continue, debug_resume, or debug_wait_for_pause. Set breakpoints in the entry script and in node_modules packages before continuing. require/import/loader are optional --require/--import/--experimental-loader injects, resolved from the program's node_modules. Child processes are auto-attached by default. Call again to debug another program in parallel. Runs the target as the MCP user. launch executes a process; evaluate runs JavaScript inside it. Only use on a trusted local workspace. Inspector is bound to 127.0.0.1.

debug_attachA

Attach to an existing Node inspector on loopback and return a new sessionId. Provide wsUrl, host+port (GET /json/list), or pid (enables inspector if needed). Runs the target as the MCP user. launch executes a process; evaluate runs JavaScript inside it. Only use on a trusted local workspace. Inspector is bound to 127.0.0.1.

debug_list_sessionsA

List all debug sessions on this MCP connection (sessionId, state, pid, program, label).

debug_disconnectA

Close one session, or all sessions if all=true. By default kills a process started by debug_launch; attached processes are left running unless terminate=true.

debug_restartA

For launch: kill the debuggee, spawn the same configuration, reapply breakpoints. For attach: disconnect CDP, rediscover the inspector, reattach, reapply breakpoints. sessionId is unchanged and this MCP connection stays up.

debug_set_breakpointA

Set a line breakpoint with Debugger.setBreakpointByUrl. file is a path or a package specifier resolved from the debuggee program node_modules. Original sources are remapped through file://, inline, or allowed http(s) source maps. Lines and columns are 1-based. logMessage is a DAP-style logpoint (interpolates {expr}, does not pause).

debug_list_breakpointsB

List breakpoints in a session.

debug_list_scriptsA

List scripts the inspector has parsed (entry, --require/--import modules, Babel plugins, node internals). Use this to find the file URL to break in an extension.

debug_remove_breakpointA

Remove a breakpoint by id returned from debug_set_breakpoint.

debug_continueA

Start the isolate if still awaiting_start, or resume a paused target. Returns immediately. Use debug_wait_for_pause after a breakpoint is expected.

debug_wait_for_pauseB

If awaiting_start, start the isolate (set breakpoints first). If paused, return the current snapshot. If running, block until Debugger.paused or timeout. Only one waiter is allowed per session.

debug_resumeA

Start or continue, then wait for the next pause. Use for scripted stepping through breakpoints. From awaiting_start, starts the isolate (set breakpoints first).

debug_pauseB

Request Debugger.pause. Returns the current snapshot if already paused.

debug_step_overB

Step over the current statement and return the new pause snapshot. Lines are 1-based.

debug_step_intoB

Step into the current call and return the new pause snapshot.

debug_step_outB

Step out of the current function and return the new pause snapshot.

debug_get_stackA

Return the current call stack. Requires a paused target. Lines are 1-based.

debug_get_variablesA

Inspect locals/closures on a paused frame, or expand an objectId from a previous result. Returns a preview: default 32 properties, cursor pages the rest, overflow/已折叠 when truncated, [Circular]/已回环 for cycles. Expand nested values with objectId. Global/script scopes are omitted unless includeGlobal or scopeIndex is set. Requires a paused target.

debug_evaluateA

Evaluate a JavaScript expression. Uses Debugger.evaluateOnCallFrame when paused, otherwise Runtime.evaluate. Runs the target as the MCP user. launch executes a process; evaluate runs JavaScript inside it. Only use on a trusted local workspace. Inspector is bound to 127.0.0.1.

debug_get_outputA

Read captured stdout, stderr, and Runtime.consoleAPICalled entries. Pass cursor from the previous response for incremental reads.

debug_statusA

Return one session's idle/connecting/paused/running/closed, pid, and inspector WebSocket URL. Omit sessionId if only one session is live.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.7/5.0

Scored across 21 tools

Disambiguation3/5

Most tool groups are clearly separated by resource (breakpoints, sessions, stepping), but debug_continue, debug_resume, debug_wait_for_pause, and debug_pause have overlapping control-flow behavior that could cause an agent to pick the wrong one. The descriptions clarify the differences, but the boundaries are still somewhat subtle.

Naming Consistency5/5

All tools use a consistent debug_ prefix with snake_case and a predictable verb_noun pattern (debug_set_breakpoint, debug_list_sessions, debug_get_variables). Phrasal verbs like debug_step_out and debug_wait_for_pause are still intuitive and fit the same scheme.

Tool Count3/5

21 tools is on the heavy side, though the domain of a Node.js debugger naturally requires many operations. The count is justified by the breadth of lifecycle, breakpoint, stepping, and inspection features, but it is still more than the typical well-scoped MCP server.

Completeness4/5

The tool surface covers the core debugging lifecycle well: launch/attach, control, breakpoints, stepping, stack/variables, evaluation, output, and session management. Minor gaps exist such as no explicit conditional breakpoint support, exception breakpoint configuration, or source retrieval, but agents can accomplish most debugging workflows.

Maintenance

ActivityMaintained
ResponsivenessNo issues