node-runtime
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NODE_RUNTIME_MCP_DEBUG | No | Set to `1` to trace every inspector protocol message on stderr. | |
| NODE_RUNTIME_MCP_BLACKBOX | No | A regex pattern for additional files to ignore-list (blackbox) so steps and pauses land in your code. Node internals (`node:*`) are always ignore-listed. Example: `node_modules`. |
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 |
|---|---|
| launchA | Start |
| attachA | Attach to a process already started with |
| disconnectA | Kill a launched process, or detach from an attached one (resuming it if paused). Breakpoints are remembered for the next launch/attach. |
| statusB | Whether a session is active, what it's attached to, paused/running, breakpoint count, and the current stack if paused. |
| set_breakpointA | Set a (optionally conditional) breakpoint at file:line. Line is 1-based. The file may not be loaded yet; the breakpoint resolves when it is. Returns the breakpoint id to use with remove_breakpoint. |
| remove_breakpointB | Remove a breakpoint by the id returned from set_breakpoint. |
| list_breakpointsB | All breakpoints with their ids, locations, conditions, resolution state and hit counts. |
| set_exception_breakpointsA | Control whether the debugger pauses when an exception is thrown. Default is 'uncaught'. |
| continueA | Resume the paused process. Returns the next pause (breakpoint, exception, debugger statement) if one happens within wait_ms, otherwise 'running'. |
| step_overA | Execute the current line and pause on the next one in the same frame. |
| step_intoA | Step into the function called on the current line (follows async calls). |
| step_outB | Run until the current function returns and pause in the caller. |
| pauseA | Interrupt a running process at the next JS execution and report where it stopped. |
| wait_for_pauseA | Block up to wait_ms for the running process to hit a breakpoint or exception, e.g. after you trigger an HTTP request against it from elsewhere. |
| get_stackA | The full call stack at the current pause: frame index, function name, file:line:col. Frame indices are used by get_scopes and evaluate. |
| get_scopesA | All variables visible in a frame (local, closure, block, module scopes, plus |
| evaluateA | Evaluate a JavaScript expression. While paused it runs in the chosen frame (default innermost) and can see locals; while running it runs in the global scope with |
| get_propertiesA | List the properties of an object by the ⟨ref …⟩ id shown by get_scopes or evaluate. Nested objects get their own refs. |
| get_outputA | stdout, stderr, console.* calls and uncaught exceptions captured from the process, newest last. Each line has a seq number; pass since_seq to get only new lines. |
| list_scriptsA | Source files the process has loaded so far (excluding node: internals). Useful to find the right path for a breakpoint. |
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 20 tools
Each tool targets a distinct debugger action: session lifecycle (launch/attach/disconnect/status), inspection (get_stack/get_scopes/get_properties/get_output/evaluate), breakpoints (set/remove/list/set_exception_breakpoints), and execution control (continue/pause/step_over/step_into/step_out/wait_for_pause). Overlaps are minimal and handled by clear scoping (e.g. evaluate vs get_properties, continue vs wait_for_pause). An agent can reliably pick the right tool.
Naming is largely readable and predictable, with verb_noun forms for most tools (get_stack, set_breakpoint, remove_breakpoint, list_breakpoints, step_over, wait_for_pause). Deviations are single-action verbs (launch, attach, disconnect, continue, pause, evaluate, status), which are conventional in debugger APIs but technically mixed with the verb_noun pattern.
At 20 tools this is on the heavier side for a typical MCP server, but the Node.js debugging domain genuinely requires lifecycle, inspection, breakpoint, and stepping primitives. Each tool appears to earn its place, with no obvious redundant entries, so the count is reasonable though slightly over the ideal 3-15 range.
Core debugger workflows are well covered: launch/attach, session teardown, breakpoint management including conditional and exception breakpoints, stack/scope/property inspection, evaluation, output capture, and full stepping controls. Minor gaps exist, such as no explicit tool to read a loaded script's source (list_scripts only enumerates paths) and no bulk breakpoint removal, but these are workable.