This server enables AI agents to debug Node.js programs through the V8 Inspector Protocol, providing full debugger-style control over a Node.js process.
reset — Launch a Node.js process with --inspect-brk, specifying the working directory, command, arguments, and optional environment variables.
stop — Terminate the current debug target and clear the session.
set_breakpoint — Add a breakpoint at a specific 0-based line number in a script matched by a URL regex.
set_pause_on_exceptions — Configure whether the debugger pauses on none, uncaught, or all exceptions (defaults to uncaught).
continue — Resume the debugged process and return immediately (useful when an external trigger is needed to hit a breakpoint).
wait_for_pause — Block until the debugged process pauses and return the current location.
resume — Resume execution and automatically wait for the next pause.
stepover — Step over the current statement and wait for the next pause.
stepinto — Step into the next function call and wait for the next pause.
getvariables — Retrieve all variables in scope for the currently paused call frame.
evaluate — Execute arbitrary JavaScript expressions in the context of the currently paused call frame and return the result.
Provides debugging capabilities for Node.js programs, including setting breakpoints, stepping, evaluating expressions, and inspecting variables via the V8 Inspector Protocol.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-debugger-node debug my Node app, set breakpoint at line 12, then step over"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for debugging Node.js programs through the V8 Inspector Protocol.
This server gives an AI agent debugger-style tools: start a Node process under
--inspect-brk, set breakpoints, continue execution, wait for pauses, step,
inspect variables, and evaluate expressions in the current call frame.
This server starts whatever command is provided in thereset target config.
Only use it in trusted local development environments. A target config can run
arbitrary commands with your user permissions.
This package is meant to be started by an MCP client over stdio:
npx -y mcp-debugger-node@betaYou usually do not run that command by hand. Instead, add it to your agent or editor MCP configuration.
The project is still in beta, so @beta is recommended until the first stable
1.0.0 release.
Add this to ~/.codex/config.toml:
[mcp_servers.node-debugger]
command = "npx"
args = ["-y", "mcp-debugger-node@beta"]Use the Claude Code MCP CLI:
claude mcp add node-debugger -- npx -y mcp-debugger-node@betaFor a project-local config, run that command from the project you want to configure.
Create or update .vscode/mcp.json:
{
"servers": {
"node-debugger": {
"type": "stdio",
"command": "npx",
"args": ["-y", "mcp-debugger-node@beta"]
}
}
}Use a stdio server entry with:
{
"command": "npx",
"args": ["-y", "mcp-debugger-node@beta"]
}Related MCP server: MCP Chrome Debugger Protocol
Start a debug session by calling reset with an explicit target:
{
"target": {
"cwd": "/path/to/project",
"command": "node",
"args": ["--inspect-brk=0", "server.js"]
}
}For a CommonJS TypeScript project using ts-node:
{
"target": {
"cwd": "/path/to/project",
"command": "node",
"args": ["--inspect-brk=0", "-r", "ts-node/register", "src/index.ts"]
}
}For an ESM TypeScript project:
{
"target": {
"cwd": "/path/to/project",
"command": "node",
"args": ["--inspect-brk=0", "--loader", "ts-node/esm", "src/index.ts"]
}
}The target must include --inspect-brk=0. The server reads the inspector URL
from the target process stderr and connects to it.
For simple scripts:
Call reset with a target.
Call set_breakpoint.
Call resume.
Call get_variables or evaluate.
Use step_over or step_into as needed.
For event-driven servers:
Call reset with a target.
Call set_breakpoint in the endpoint or handler.
Call continue.
Trigger the event with curl, a browser, a test runner, or another tool.
Call wait_for_pause.
Inspect runtime state with get_variables and evaluate.
Call continue again to let the request finish.
Example endpoint debugging flow:
{
"urlRegex": "server\\.js$",
"lineNumber": 42
}Then:
continue
curl http://localhost:3000/api/users
wait_for_pause
evaluate {"expression":"req.url"}
get_variables
continueresetRestart the debug session with a fresh Node inspector process.
Input:
{
"target": {
"cwd": "/path/to/project",
"command": "node",
"args": ["--inspect-brk=0", "server.js"],
"env": {
"NODE_ENV": "development"
}
}
}env is optional and is merged with the MCP server environment.
set_breakpointSet a breakpoint by matching a script URL with a regex.
Input:
{
"urlRegex": "server\\.js$",
"lineNumber": 10
}lineNumber is zero-based, matching the Chrome DevTools Protocol.
set_pause_on_exceptionsConfigure exception pause behavior.
Input:
{
"state": "uncaught"
}Allowed states:
none
uncaught
all
The default is uncaught.
continueResume execution and return immediately.
Use this when some external action needs to trigger the breakpoint, such as a curl request or browser interaction.
wait_for_pauseWait until the debugged process pauses and return the current location.
Useful after continue when another tool is triggering the application.
resumeResume execution and wait for the next pause.
This is convenient for scripts where the next pause will happen without an external trigger.
step_overStep over the current statement and wait for the next pause.
step_intoStep into the next function call and wait for the next pause.
get_variablesGet variables for the latest paused call frame scope.
evaluateEvaluate JavaScript in the latest paused call frame.
Input:
{
"expression": "JSON.stringify(req.body)"
}The debugger pauses on uncaught exceptions by default. When an exception pause happens, the pause result includes exception metadata:
{
"reason": "exception",
"lineNumber": 8,
"columnNumber": 3,
"exception": {
"className": "Error",
"description": "Error: file is not a database ..."
}
}This lets agents diagnose startup crashes and runtime failures without reading server logs.
Resume execution of the debugged Node.js process and return immediately.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states 'resume execution' and 'return immediately', which are key traits. However, it does not mention failure states, required process state, or side effects (e.g., permanent continuation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundant words. Clearly conveys purpose and behavior efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description covers the essential action and non-blocking return. However, it lacks comparison to the sibling 'resume', which could cause confusion for an agent selecting tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema description coverage is 100%. Baseline for 0 parameters is 4. The description need not add param details, and it doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action 'Resume execution' and targets 'debugged Node.js process'. It adds 'return immediately' to clarify non-blocking behavior. This distinguishes it from siblings like 'stepinto' or 'stepover' but is similar to 'resume'; however, the description is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, such as the sibling 'resume'. There is no mention of prerequisites (e.g., process must be paused) or scenarios where this is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate a JavaScript expression in the debugged runtime.
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes | JavaScript expression to evaluate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose that evaluating expressions may have side effects, asynchronous behavior, or security implications. For a tool executing arbitrary code, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, front-loaded with key information. Efficient but could be expanded slightly without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output schema, no mention of return values, error handling, side effects, or async behavior. Incomplete for a potentially powerful debugger tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes the 'expression' parameter. The description adds minimal extra meaning beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (evaluate) and resource (JavaScript expression in the debugged runtime). It distinguishes well from sibling tools like getvariables or stepinto.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., getvariables for variable inspection). No mention of when not to use it or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get variables for the latest paused call frame scope.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It states the scope but doesn't mention what happens if no call frame is paused or how variables are returned. Minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 8 words, front-loaded with purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is adequate for a simple debugger tool. Could mention return format, but not necessary for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is 100%. The description provides sufficient context for a zero-parameter tool, meeting the baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves variables for the latest paused call frame, differentiating it from sibling tools like evaluate or stepover.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use when debugger is paused by specifying 'latest paused call frame', but could explicitly state when not to use it or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restart the debug session with a fresh Node inspector process for the provided target.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Debug target to start. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It indicates a restart with a fresh process (implying destruction of the old session), but does not disclose details like whether state is preserved, if it's asynchronous, or what happens to breakpoints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and to the point. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested parameter structure and lack of output schema, the description is too brief. It does not explain return behavior, side effects, or interaction with sibling tools, leaving critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each property. The description adds no extra meaning beyond the schema; it does not clarify parameter nuances or provide examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('restart the debug session') and the method ('fresh Node inspector process'). It uses specific verbs and resource ('restart', 'debug session'), distinguishing it from sibling tools like 'continue' or 'resume'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not state prerequisites (e.g., an existing debug session) or provide examples of when a restart is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resume execution of the debugged Node.js process and wait for the next pause.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions waiting for the next pause but does not disclose prerequisites (e.g., must be in paused state), side effects, or error conditions. The behavior is partially clear but lacks sufficient detail for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 14 words, perfectly concise with no extraneous information. It is front-loaded and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of sibling tools like 'continue' and 'stepover', the description lacks contextual completeness. It does not explain the difference from 'continue' (which might imply the same behavior) or mention that the process must be paused. The simple nature reduces the need, but more context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The description does not need to add parameter info. The baseline for 0 parameters is 4, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Resume execution') and the specific resource ('debugged Node.js process'), with an additional detail about waiting for the next pause. It is unambiguous but does not explicitly differentiate from sibling tools like 'continue'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives such as 'continue', 'stepinto', or 'stepover'. The description only states what it does, not the context or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a breakpoint by matching a script URL with a regex.
| Name | Required | Description | Default |
|---|---|---|---|
| urlRegex | Yes | Regex matching the script URL (e.g. 'src/foo\\.ts') | |
| lineNumber | Yes | 0-based line number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose side effects, what happens if regex fails, whether it modifies state, or if it requires a running session.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action and resource, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool without output schema, the description is adequate but lacks information on behavior after setting (persistence, overwriting, removal).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains parameters. The description adds no new semantic value beyond reinforcing the regex matching aspect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action (set a breakpoint) and mechanism (matching a script URL with a regex). It distinguishes itself from sibling debugger control tools like continue, stepinto, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No mentions of prerequisites, conditions, or exclusions. The description only states what it does, not when.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure whether the debugger pauses on no exceptions, uncaught exceptions, or all exceptions.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Which exceptions should pause the debugger. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly conveys the behavioral effect of the tool: it configures the debugger to pause on no exceptions, uncaught exceptions, or all exceptions. Since no annotations are provided, the description sufficiently fills the transparency gap, though it does not mention side effects or state implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose. It contains no unnecessary words and is well-front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is sufficient. It explains the core functionality without needing to detail return values or error conditions. However, it could mention if the change takes immediate effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter 'state' with a description. The tool description adds marginal value by paraphrasing the enum values ('no exceptions, uncaught exceptions, or all exceptions'), but schema coverage is 100%, so baseline is met.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: configuring the debugger's behavior for pausing on exceptions. It uses a specific verb ('configure') and resource (pause-on-exception behavior), and distinguishes itself from sibling tools like 'continue' or 'set_breakpoint'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios where changing exception pause settings is appropriate, nor does it explain when other debugger tools might be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step into the next function call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action without explaining side effects, prerequisites, or behavior when no function call exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence efficiently conveys the purpose. However, for a debugging tool, additional context could be added without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description is minimally adequate. It lacks context about what happens after stepping into a function or how it fits into the debugging workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description adds value by explaining the tool's purpose, though no parameter details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Step into') and the target ('the next function call'), distinguishing it from sibling tools like 'stepover' (step over) and 'continue' (continue execution).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Siblings are listed but no context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step over the current statement.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states the action; it does not disclose what happens after stepping over (e.g., pausing, return values) or any behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words; it is appropriately front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of parameters, output schema, and annotations, the description is minimally complete but could benefit from clarifying the effect (e.g., moves to next line without entering functions).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description does not need to add parameter details; baseline 4 as per rubric for 0 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'step over' and the resource 'current statement', which is specific and distinct from sibling tools like stepinto (step into) and continue (resume execution).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like stepinto or continue; the description only states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop the current debug target and clear the debug session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does not disclose side effects or whether the debugging process is killed or just suspended; the description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words; it is as concise as possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description covers the essential action, though it could mention if debug state is lost.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%; the description adds no parameter info, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Stop' and the resource 'current debug target', and distinguishes from sibling tools like pause or step by specifying clearing the session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like pause or reset; the context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait until the debugged Node.js process pauses and return the current location.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description bears full burden. It discloses the blocking wait and return of location, but lacks details on timeout, state effects, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently communicates the tool's action and output without excess.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions returning 'current location' but does not specify the format or what constitutes a location (e.g., file and line number). Some ambiguity remains for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and baseline for 0 params is 4. The description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits for a pause and returns the current location, distinguishing it from sibling tools like 'continue' or 'stepinto'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to wait for a debugger pause, but does not explicitly state when not to use or offer alternatives. Context from sibling tools helps clarify purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0continueevaluategetvariablesresetresumeset_breakpointset_pause_on_exceptionsstepintostepoverstopwait_for_pauseEach tool has a distinct purpose with clear descriptions; continue and resume are differentiated by return behavior, and all other tools target unique debugger actions.
Tool names mix single-word verbs (continue, stop) with underscore-separated phrases (set_breakpoint, wait_for_pause), and 'getvariables' lacks a separator, creating an inconsistent pattern.
11 tools cover essential debugger operations without being excessive, fitting well within the typical 3-15 range for a focused domain.
Missing critical features like removing or listing breakpoints, retrieving call stacks, and setting variables, which are essential for productive debugging sessions.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for understanding Javascript internals from ECMAScript specification.
Live browser debugging for AI assistants — DOM, console, network via MCP.
Agent Replay Debugger MCP — record every agent step + deterministic replay. Step-debugger for
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mohammed-almassri/mcp-debugger-node'
If you have feedback or need assistance with the MCP directory API, please join our Discord server