Everything here assumes the process is already up and misbehaving: set a breakpoint by file and line, wait for the pause, then read the scope and evaluate expressions against the real values rather than the ones you predicted when you added logging. nodejs_inspect runs arbitrary JavaScript inside the debugged process, which is both what makes the tool useful and the reason to point it only at processes that are yours.
A debugger front end for a live Node.js process, exposing breakpoints, stepping, scope inspection and expression evaluation as tools.
- Breakpoints set by file and line, listed while active, and deleted by breakpointId
- Stepping once execution is paused — over, into and out — plus continue to let it run on
- The variables in the current scope and the execution location while paused
- Expressions evaluated in the current context, and JavaScript executed inside the debugged process
- The most recent console output from the process being debugged, bounded by a limit
- A manual reconnection attempt against a port when the attachment drops
A Node.js process already running with its debugger listening on a port you can reach. These tools attach to that process; they do not start it.
One command — npx -y @hyperdrive-eng/mcp-nodejs-debugger