xcnodejs-debugger-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 21 tools
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.
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.
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.
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.