Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
NODE_RUNTIME_MCP_DEBUGNoSet to `1` to trace every inspector protocol message on stderr.
NODE_RUNTIME_MCP_BLACKBOXNoA 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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
launchA

Start node <script> [args] with the inspector attached. The process is paused at its first line until breakpoints are applied, then resumed unless stop_on_entry is true. Any previous session is torn down first.

attachA

Attach to a process already started with node --inspect or --inspect-brk (default 127.0.0.1:9229). Does not take ownership of the process; disconnect detaches and lets it keep running. Breakpoint paths are resolved against the server's cwd unless they're absolute.

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 this), with values. Object values come with a ⟨ref⟩ you can expand with get_properties.

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 require available (paths relative to the process cwd) and awaits promises. Side effects are allowed, so this can also mutate state or call functions. If the expression calls into code that hits a breakpoint, the pause is reported and the process stays paused there.

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.8/5.0

Scored across 20 tools

Disambiguation5/5

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 Consistency4/5

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.

Tool Count4/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues