MCP SERVERGives the assistant a real debugger: attach to a running Node or Chrome process, set a breakpoint, step through it, and read — or change — the variables at the point where it broke.
LABSCO SUMMARY
The usual pattern — add a log line, rerun, read the output, repeat — collapses when the assistant can stop the program at the line in question and evaluate expressions against the live frame. Two things are worth setting up first: start with --inspect-brk so nothing important has run before you attach, and use conditional breakpoints on anything inside a loop, or you will spend the session resuming. Source-map support is what makes it usable on TypeScript and bundled code rather than only on plain JavaScript.
A Chrome DevTools Protocol client. It attaches to any CDP-capable runtime over a WebSocket URL and exposes the normal debugger operations as tools, with source maps resolved so transpiled code maps back to what you wrote.
A process to attach to, started with the inspector — node --inspect-brk=9229 pauses on the first line, which is what you want if the bug happens during startup, and node --inspect=9229 does not. The WebSocket URL comes from the runtime's own endpoint listing, and it is what the connect call takes. The server runs as npx mcp-js-debugger. Debugging is stateful: most tools need the session paused, and disconnecting drops every breakpoint set in that session. The debugger can change variables in the running program, so it acts on the process, not just observes it.
One command — npx mcp-js-debugger
USE CASES
Attach to the process, break on the line, and read the scope variables and call stack at the moment it goes wrong.
Set a conditional breakpoint so execution stops only when the expression is true, instead of on every pass through the loop.
Change a variable's value in the paused frame and let execution continue, to see whether that was really the cause.
Turn on pausing for exceptions, let the program run, and read the stack at the throw rather than at the catch.
List the loaded scripts with their source-map information, map the generated location back to the original, and read the original source.
Step into the call, look around, then step out again to get back to where you were.
Counted once with only startup setup. Other versions, modes or optional credentials may expose a different list.
connect_debuggerEstablishes a new debugging session by connecting to a Chrome DevTools Protocol (CDP) endpoint. Use this to connect to Node.js (started with --inspect), Chrome, Edge, or other CDP-compatible runtimes. Returns a session_id that must be used in all subsequent debugging operations.
disconnect_debuggerCloses an active debugging session and releases all resources. Any breakpoints set in the session will be removed.
evaluate_expressionEvaluates a JavaScript expression in the context of a specific call frame or global context. Use this to inspect variables, test expressions, or understand the program state. The expression is evaluated in the JavaScript runtime, so you can call methods, access properties, etc.
get_call_stackRetrieves the current call stack when execution is paused. Shows the chain of function calls that led to the current location, including function names, file locations, and scope information. If source maps are available, original source locations are included.
get_original_locationMaps a generated code location back to the original source location using source maps. Essential for debugging bundled or transpiled code (TypeScript, Babel, webpack, esbuild, etc.).
get_scope_variablesRetrieves all variables in a specific scope. Use this to see all local variables, closure variables, or global variables at a given point in execution.
get_script_sourceRetrieves the source code for a script. If source maps are available, can return the original source instead of the generated/bundled code.
list_breakpointsLists all breakpoints set in a debugging session, including their locations and conditions.
list_scriptsLists all scripts loaded in the debugging session. Includes source map information where available, showing which original sources are mapped.
pause_executionPauses execution at the next possible opportunity. Use this when the program is running and you want to inspect its state.
remove_breakpointRemoves a previously set breakpoint. Use list_breakpoints to find breakpoint IDs.
resume_executionResumes execution after being paused at a breakpoint or by pause_execution. Execution continues until the next breakpoint or the program ends.
set_breakpointSets a breakpoint at a specific location in the code. The breakpoint will pause execution when the specified line is reached. You can set conditional breakpoints that only trigger when an expression evaluates to true.
set_pause_on_exceptionsConfigures whether the debugger should pause when exceptions are thrown. Useful for catching errors as they occur.
set_variable_valueModifies the value of a variable in a specific call frame. Use this to test different scenarios or fix values during debugging.
step_intoSteps into a function call if the current line contains one, otherwise steps to the next statement. Use this to examine what happens inside a function. The session must be paused.
step_outSteps out of the current function and pauses at the calling code. Use this to quickly exit a function you've stepped into. The session must be paused.
step_overSteps over the current statement to the next line in the same function. If the current line contains a function call, the entire function executes without stepping into it. The session must be paused.
BEFORE YOU INSTALL
18 tools when we connected.
The documented client runs the server on your machine.
CONTEXT COST
Rated by the size of the 18 tool definitions that ride along on every turn, not by how many there are
INSTALLATION
npx mcp-js-debugger{
"mcpServers": {
"mcp-js-debugger": {
"command": "npx",
"args": [
"mcp-js-debugger"
]
}
}
}MCP servers
ScriptedAlchemy
benjaminr
vola-trebla
introfini