Enables debugging of Node.js applications through the Chrome DevTools Protocol, allowing breakpoint management, code stepping, call stack inspection, variable examination, and expression evaluation with source map support for transpiled code.
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 JS Debugger set a breakpoint at line 25 in app.js and step through the function"
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.
An MCP (Model Context Protocol) server that exposes Chrome DevTools Protocol debugging capabilities, enabling AI assistants to debug JavaScript and TypeScript applications.
Connect to any CDP-compatible debugger (Node.js, Chrome, Edge)
Set, list, and remove breakpoints
Step through code (over, into, out)
Inspect call stacks with source map support
Evaluate expressions in any stack frame
View and modify variables
Pause on exceptions
Full source map support for debugging transpiled code
Related MCP server: MCP Debugger
npm install
npm run buildAdd to your Claude Code configuration:
claude mcp add mcp-js-debugger -- npx mcp-js-debuggerOr add to .mcp.json:
{
"mcpServers": {
"mcp-js-debugger": {
"command": "npx",
"args": ["mcp-js-debugger"]
}
}
}Start your Node.js application with the inspector:
# Pause on first line (recommended for setting initial breakpoints)
node --inspect-brk=9229 your-script.js
# Or start without pausing
node --inspect=9229 your-script.jsTool | Description |
| Connect to a CDP endpoint via WebSocket URL |
| Disconnect from a debugging session |
| Set a breakpoint by URL and line number |
| Remove a breakpoint by ID |
| List all breakpoints in a session |
| Resume execution after pause |
| Step over the current statement |
| Step into a function call |
| Step out of the current function |
| Pause running execution |
| Get the current call stack with source locations |
| Evaluate a JavaScript expression |
| Get variables in a scope |
| Modify a variable's value |
| Configure exception handling |
| Map generated to original source location |
| Get script source code |
| List loaded scripts |
Start your application with --inspect-brk:
node --inspect-brk=9229 app.jsGet the WebSocket URL:
curl http://localhost:9229/jsonConnect the debugger:
connect_debugger(websocket_url: "ws://localhost:9229/<id>")Set breakpoints:
set_breakpoint(session_id: "...", url: "file:///path/to/app.js", line_number: 10)Resume execution to hit the breakpoint:
resume_execution(session_id: "...")Inspect state when paused:
get_call_stack(session_id: "...")
get_scope_variables(session_id: "...", call_frame_id: "...", scope_index: 0)
evaluate_expression(session_id: "...", expression: "myVariable")Continue debugging:
step_over(session_id: "...")
resume_execution(session_id: "...")The server automatically loads source maps for transpiled code (TypeScript, bundled JavaScript, etc.). When source maps are available:
Call stacks show original source locations
Breakpoints can be set on original source files
get_original_location maps generated positions to original source
get_script_source can return original source content
# Build
npm run build
# Run tests
npm test
# Run tests with coverage
npm run test:coverage
# Watch mode for development
npm run devcdp-client.ts - Low-level Chrome DevTools Protocol client wrapper
session-manager.ts - Manages multiple debugging sessions
source-map-manager.ts - Handles source map loading and position mapping
server.ts - MCP server implementation with tool handlers
types.ts - TypeScript type definitions
Node.js 18.0.0 or later
A CDP-compatible debug target (Node.js, Chrome, Edge, etc.)
Apache-2.0
Establishes 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.
| Name | Required | Description | Default |
|---|---|---|---|
| websocket_url | Yes | WebSocket URL for the CDP endpoint. For Node.js, this is typically ws://localhost:9229/{uuid}. For Chrome, use ws://localhost:9222/devtools/page/{pageId}. You can find available targets by visiting http://localhost:9229/json (Node.js) or http://localhost:9222/json (Chrome). | |
| session_name | No | Optional human-readable name for this debugging session. Useful when managing multiple concurrent sessions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses that a session_id is returned and must be used subsequently, and describes the target CDP endpoint types. However, it does not mention error conditions (e.g., connection failures), side effects, or permissions needed, leaving gaps in behavioral transparency.
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 two sentences, front-loading the primary purpose. Every sentence adds value: first sentence defines the tool, second gives usage context and result. No unnecessary words, achieving high 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 the moderate complexity (2 params, no output schema, no annotations), the description covers the essential purpose, usage context, and the key output (session_id). It lacks details about error handling or lifecycle (e.g., need to disconnect), but the presence of a disconnect sibling mitigates this. Overall fairly complete.
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 baseline is 3. The description in the tool text adds no additional parameter semantics beyond what is already in the schema's parameter descriptions, which are thorough. Thus, the description does not increase the understanding of parameters beyond the schema.
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 explicitly states 'establishes a new debugging session by connecting to a Chrome DevTools Protocol endpoint,' clearly indicating the action (connect) and resource (debugging session). It distinguishes from sibling tools as the entry point for debugging operations, and mentions the returned session_id required for subsequent calls.
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 gives concrete when-to-use guidance: 'Use this to connect to Node.js, Chrome, Edge, or other CDP-compatible runtimes.' It implies that after connection, other debug tools are used. However, it does not explicitly state when not to use or mention alternative tools, though the sibling list makes this clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Closes an active debugging session and releases all resources. Any breakpoints set in the session will be removed.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ID of the debugging session to disconnect. Obtain this from connect_debugger or the debug://sessions resource. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses that resources are released and breakpoints are removed. Could be improved by noting irreversibility, but sufficient for a simple disconnect action.
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?
Two concise sentences, front-loaded with the main action, no redundant information. Every sentence adds value.
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 one parameter and no output schema, the description covers the main purpose and side effects. Could mention return value or confirmation, but not essential.
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% and the schema description of session_id is clear. The tool description adds no extra parameter semantics beyond what the schema provides, so baseline 3 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 verb 'Closes' and resource 'debugging session', and mentions side effect on breakpoints. It effectively distinguishes from sibling tools like connect_debugger and 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?
Usage context is implicitly clear (after debugging is done), but there is no explicit guidance on when not to use it or alternatives. The mention of breakpoint removal provides some caution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluates 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.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ID of the debugging session. | |
| expression | Yes | JavaScript expression to evaluate. Examples: "myVariable", "array.length", "JSON.stringify(data)", "obj.method()" | |
| call_frame_id | No | Optional call frame ID to evaluate in. If not provided, evaluates in the global context. Obtain call_frame_id from get_call_stack. Evaluating in a frame provides access to local variables. | |
| return_by_value | No | Whether to return the result by value (serialised) or as a remote object reference. Defaults to true. Set to false for large objects to avoid serialisation overhead. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the expression runs in the JavaScript runtime, can call methods and access properties, and mentions the return_by_value option's serialization behavior. This is sufficient for a debugger tool.
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 two sentences, front-loaded with the core purpose, and each sentence adds necessary detail. 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?
With 4 parameters and no output schema, the description adequately covers evaluation behavior, parameter usage, and context. It could mention that the result is a RemoteObject, but the return_by_value parameter covers serialization. Overall complete for its complexity.
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?
Input schema has 100% description coverage, but the description adds value by providing usage examples for the 'expression' parameter and clarifying that 'call_frame_id' can be obtained from get_call_stack. The examples help an agent form correct expressions.
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 evaluates JavaScript expressions in a debugging context, with explicit examples like 'myVariable', 'array.length', and 'JSON.stringify(data)'. It distinguishes itself from siblings by specifying it's for inspecting variables, testing expressions, and understanding program state.
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 explains when to use the tool (inspect variables, test expressions) and provides context about call frames vs global context. However, it does not explicitly state when not to use it or contrast with sibling tools like get_scope_variables or set_variable_value.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves 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.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ID of the debugging session. The session must be paused. | |
| include_async | No | Whether to include asynchronous stack traces (Promise chains, async/await). Defaults to true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully covers behavior: it lists the information included in the call stack (function names, file locations, scope information) and mentions that original source locations are included if source maps are available. This sufficiently discloses the tool's output and conditions.
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 consists of three sentences with no wasted words. The first sentence immediately states the main purpose, and the following sentences provide necessary details. It is well-structured and 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 there is no output schema, the description adequately explains what the tool returns (function names, file locations, scope info) and the condition under which it works (execution paused). It also mentions source maps, which adds completeness without requiring additional explanation.
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 has 100% description coverage, so the baseline is 3. The description does not add new information about the parameters beyond the schema, but it provides context about the output that indirectly helps understand the parameters. No contradiction or extra detail on 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 that the tool retrieves the current call stack when execution is paused. It uses a specific verb ('retrieves') and resource ('call stack'), and distinguishes itself from sibling debugger tools like 'step_into' or 'evaluate_expression' which have different purposes.
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 specifies that the tool should be used 'when execution is paused', providing clear context. However, it does not explicitly mention when not to use it or list alternative tools for different scenarios, though the sibling names imply other debugger operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Maps 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.).
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ID of the debugging session. | |
| script_id | Yes | ID of the script containing the generated code. Obtain from list_scripts or get_call_stack. | |
| line_number | Yes | Line number in the generated code (1-based). | |
| column_number | Yes | Column number in the generated code (0-based). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It states the tool uses source maps but does not disclose behavior if source maps are missing, whether it is read-only, or any required permissions.
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?
Two sentences, front-loaded with the primary action, and every word serves a purpose. No extraneous content.
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 mapping tool with four well-documented parameters, the description is adequate. It could mention dependency on an active debugging session or source map availability, but the current text is sufficient for its complexity.
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 100% of parameters with clear descriptions. The tool description adds context about source maps but does not provide additional semantic detail beyond the schema.
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 uses a specific verb 'maps' and identifies the resource as 'generated code location to original source location'. It clearly distinguishes this tool from sibling tools like get_call_stack or get_script_source by focusing on source map resolution.
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 for debugging bundled/transpiled code but does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves all variables in a specific scope. Use this to see all local variables, closure variables, or global variables at a given point in execution.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ID of the debugging session. The session must be paused. | |
| call_frame_id | Yes | ID of the call frame. Obtain this from get_call_stack. | |
| scope_index | No | Index of the scope in the scope chain. 0 is the local scope, higher indices are closure and global scopes. Defaults to 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions retrieving variables but does not disclose side effects, permissions, or that the session must be paused (only indicated in schema). No mention of return format or read-only nature limits transparency.
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 two sentences, front-loaded with the main action, and every sentence provides value. No redundant or extraneous information.
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 complexity (3 parameters, no output schema), the description lacks return format details (e.g., list of variable name-value pairs). It also does not clarify that the tool is non-destructive. While adequate for basic understanding, gaps remain for complete autonomy.
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% and already documents each parameter. The description only reinforces scope types (local, closure, global) already implied by scope_index. No additional meaning or constraints are added beyond the schema.
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 uses a specific verb 'Retrieves' and resource 'all variables in a specific scope', and explicitly mentions local, closure, and global variables, making the purpose clear and distinct from sibling tools like 'evaluate_expression' or 'set_variable_value'.
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 states 'Use this to see all local variables, closure variables, or global variables', providing clear usage context. However, it does not explicitly exclude alternatives or mention when not to use it, which would improve differentiation from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves the source code for a script. If source maps are available, can return the original source instead of the generated/bundled code.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ID of the debugging session. | |
| script_id | Yes | ID of the script. Obtain from list_scripts or get_call_stack. | |
| prefer_original | No | If true and a source map exists, return the original source (e.g., TypeScript). Defaults to true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses behavior regarding source maps but omits details like error handling, permissions, or side effects. The read-only nature is implied but not explicit.
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?
Two sentences, no fluff. The main action is front-loaded, and the source map behavior is a concise addition.
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?
No output schema, so description should explain return value, but it does not. It mentions source map handling but omits error cases, permissions, or how script_id is obtained beyond sibling 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?
Schema description coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it merely restates param names. Schema already defines each parameter well.
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 'Retrieves the source code for a script', using a specific verb and resource. It distinguishes itself from siblings like list_scripts or get_call_stack by focusing on source retrieval, and adds nuance about source maps.
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 when to use (when you need source code), but lacks explicit guidance on when not to use or alternatives. No comparison to siblings like get_original_location or evaluate_expression.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all breakpoints set in a debugging session, including their locations and conditions.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ID of the debugging session. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It states the tool lists breakpoints, which is a read-only operation, but does not disclose return behavior (e.g., empty list handling) or any side effects. 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, front-loaded with key 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?
Given no output schema, description mentions output includes locations and conditions, which is informative. However, it lacks details on return format or possible edge cases. Adequate for a simple list tool but not comprehensive.
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 already describes session_id parameter with 100% coverage. Description does not add extra meaning beyond the schema, so baseline 3 applies.
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?
Description clearly states verb 'lists' and resource 'breakpoints in a debugging session', and includes details about locations and conditions. This distinguishes it from siblings like set_breakpoint and remove_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?
No guidance on when to use this tool versus alternatives. Does not mention when not to use or provide context about prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all scripts loaded in the debugging session. Includes source map information where available, showing which original sources are mapped.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ID of the debugging session. | |
| include_internal | No | Include internal scripts (node_modules, Node.js built-ins). Defaults to false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It accurately describes the operation as a listing with source map info, but does not disclose potential side effects, error conditions, or performance implications. The behavior is predictable for a debugger tool, so a 3 is appropriate.
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 consists of two sentences, with the primary purpose stated immediately. Every word contributes meaning, and there is no redundancy or extraneous information.
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 that there is no output schema, the description could provide more detail about what information is returned for each script (e.g., script ID, URL, source map status). It mentions source map information but omits other common fields, leaving the return format somewhat underspecified.
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 both parameters. The description does not add any additional context or nuance beyond what the schema provides, meeting the baseline without enhancing parameter understanding.
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 lists all scripts in the debugging session, specifying that source map information is included where available. This distinguishes it from sibling tools like get_script_source (retrieves a single script's source) and get_original_location (maps locations), making the purpose unambiguous.
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 for viewing all loaded scripts, likely to obtain script IDs for use with other tools, but it does not explicitly state when to use it versus alternatives or provide guidance on prerequisites like an active debugging session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pauses execution at the next possible opportunity. Use this when the program is running and you want to inspect its state.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ID of the debugging session. The session must be running. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that pausing is not immediate but 'at the next possible opportunity'. No annotations exist, so description covers key behavioral trait. Could mention reversibility via resume_execution.
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?
Two sentences with no filler, directly stating action and usage context. Optimal length for a simple tool.
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?
Fully describes purpose and usage context for a simple pause operation. No output schema needed; siblings cover related actions.
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 covers 100% of parameters with descriptions. Description adds no new parameter information beyond the schema, so baseline score of 3 applies.
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?
Description clearly states the action ('pauses execution') and context ('at the next possible opportunity'), differentiating it from sibling tools like set_breakpoint or step_into.
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?
Provides explicit usage condition: 'when the program is running and you want to inspect its state'. Lacks comparison to alternatives like set_breakpoint, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Removes a previously set breakpoint. Use list_breakpoints to find breakpoint IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ID of the debugging session. | |
| breakpoint_id | Yes | ID of the breakpoint to remove. Obtain this from set_breakpoint or list_breakpoints. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states removal of a breakpoint, which is adequate for a simple destructive action. However, it doesn't mention any side effects, permissions, or implications beyond the obvious.
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, brief sentence with a useful hint. It is front-loaded and contains no redundant information.
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, no output schema, and 100% schema coverage, the description is complete. It tells what it does and how to get the required ID, fitting well with sibling debugger 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?
Input schema has 100% description coverage for both parameters. The description adds minimal value beyond the schema, only reinforcing the hint for breakpoint_id. Baseline is 3 for high schema coverage.
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 'Removes a previously set breakpoint,' using a specific verb and resource. It distinguishes from sibling tools like set_breakpoint and list_breakpoints.
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 a clear usage hint: 'Use list_breakpoints to find breakpoint IDs.' While it doesn't explicitly list when not to use or alternatives, it gives context for obtaining the required parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resumes execution after being paused at a breakpoint or by pause_execution. Execution continues until the next breakpoint or the program ends.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ID of the debugging session. The session must be paused. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that execution continues until next breakpoint or program end. No annotations provided, but description covers basic behavior. Lacks details on side effects or error conditions.
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?
Two concise sentences that front-load the action and condition. 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?
For a simple tool with one parameter and no output schema, the description fully explains the effect and stopping condition. Could mention that the session must be in paused state, but this is implied by schema requirement.
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 baseline is 3. Description does not add any additional meaning or constraints beyond the schema for the session_id parameter.
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?
Clearly states the action (resume execution) and the condition (paused at breakpoint or by pause_execution). Distinguishes from sibling tools like pause_execution and step commands.
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?
Describes when to use (after pausing), but does not explicitly exclude other scenarios or compare with alternatives like step commands or evaluate_expression.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sets 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.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ID of the debugging session. | |
| url | Yes | URL of the script where the breakpoint should be set. For Node.js, use file:// URLs (e.g., file:///path/to/script.js). For remote scripts, use the full URL. Use list_scripts to find available scripts. | |
| line_number | Yes | Line number (0-based) where the breakpoint should be set. Note: Most editors display 1-based line numbers, so subtract 1. | |
| column_number | No | Optional column number (0-based). Useful for setting breakpoints in minified code. | |
| condition | No | Optional JavaScript expression. The breakpoint only triggers when this expression evaluates to true. Example: "count > 100" or "user.name === 'admin'" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description should fully disclose behavioral traits. It only states that breakpoints pause execution, but omits details like performance impact, persistence, maximum breakpoints, or behavior on invalid session/url.
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?
Extremely concise at two sentences, no wasted words. Front-loaded with the core action and behavior.
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 complexity of five parameters and no output schema, the description lacks crucial context such as error handling, expected return value or confirmation, interaction with other breakpoint tools, and edge cases like duplicate breakpoints or invalid line numbers.
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% and each parameter is well-documented in the schema. The description adds the concept of conditional breakpoints, but the condition parameter is already explained in schema. Baseline 3 applies due to high schema coverage.
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?
Clearly states the tool sets a breakpoint at a specific location (url and line number) and mentions conditional breakpoints. Distinguishes clearly from sibling tools like remove_breakpoint or list_breakpoints.
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 usage for debugging but lacks explicit guidance on when to use this tool versus other breakpoint-related tools (e.g., set_pause_on_exceptions) or when not to use it. No mention of prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configures whether the debugger should pause when exceptions are thrown. Useful for catching errors as they occur.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ID of the debugging session. | |
| state | Yes | When to pause: "none" (never pause on exceptions), "uncaught" (pause only on uncaught exceptions), "all" (pause on all exceptions, including caught ones). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose persistence, scope (session vs global), default state, or interaction with other breakpoints. The description only states the obvious.
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?
Two sentences, no extraneous words. The first sentence defines the action, the second provides a use case. Efficient and 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?
Lacks important details: no output schema, no annotations, no mention of session lifecycle, default behavior, or implications. Given the number of siblings, more context about when and how to use is necessary.
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 baseline is 3. The description adds no new meaning beyond the schema; it merely restates the high-level purpose. The schema already explains the enum values and required 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 tool configures pause-on-exception behavior using specific verb 'configures' and resource 'debugger'/'exceptions'. It is distinct from siblings like set_breakpoint or pause_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?
The phrase 'Useful for catching errors as they occur' provides a generic use case but no explicit guidance on when to use vs alternatives (e.g., breakpoints), when not to use, or how it differs from other pause options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Modifies the value of a variable in a specific call frame. Use this to test different scenarios or fix values during debugging.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ID of the debugging session. The session must be paused. | |
| call_frame_id | Yes | ID of the call frame containing the variable. Obtain from get_call_stack. | |
| scope_index | Yes | Index of the scope containing the variable. 0 is the local scope. | |
| variable_name | Yes | Name of the variable to modify. | |
| new_value | Yes | JavaScript expression that evaluates to the new value. Examples: "42", "'new string'", "{a: 1, b: 2}", "null" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It states the tool modifies values, but doesn't disclose that the session must be paused (though noted in session_id schema) or any side effects. The description is adequate but misses some behavioral context that would be helpful for an agent.
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?
Two sentences efficiently cover purpose and usage. No redundancy or unnecessary details. Every sentence adds value.
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 complexity (5 required params, no output schema, no annotations), the description covers purpose and usage but lacks mention of the paused session requirement and potential side effects. It is adequate but not fully complete for an agent to understand all contextual constraints.
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 description does not need to add parameter details. The description adds no extra meaning beyond the schema. Baseline 3 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 it 'modifies the value of a variable in a specific call frame,' which is a specific verb+resource combination. It is easily distinguishable from sibling tools like evaluate_expression (read-only) and get_scope_variables (retrieval).
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 explicit usage context: 'Use this to test different scenarios or fix values during debugging.' It does not explicitly list when not to use or alternative tools, but the guidance is strong enough to inform agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Steps 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.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ID of the debugging session. The session must be paused. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the conditional step-in behavior and the pause requirement, but lacks details on failure modes, side effects, or state changes beyond the step operation.
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 two sentences with the main action front-loaded. Every word serves a purpose, and there is no unnecessary repetition.
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 one-parameter tool with no output schema, the description covers the core behavior, when to use, and prerequisites. It is mostly complete, though it could mention the effect on execution state.
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?
With 100% schema coverage, the baseline is 3. The description repeats the session pause prerequisite, adding marginal value. No further format or validation details are provided.
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 steps into a function call if present, otherwise steps to the next statement. This specifies the verb and resource, and the conditional behavior distinguishes it from siblings like step_over or step_out.
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?
It explicitly says 'Use this to examine what happens inside a function' and notes the session must be paused. While it does not state when not to use it, the context is clear and the prerequisite is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Steps 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.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ID of the debugging session. The session must be paused. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions the precondition but does not elaborate on side effects or whether stepping out implies a breakpoint hit. Adequate but 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?
Two sentences, no wasted words. Essential information 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?
For a simple debug action without output schema, the description covers purpose, usage, and precondition. It could mention that stepping out only works if currently stepping through a function call.
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 covers 100% of parameters; description adds no extra meaning beyond the schema's description of session_id. Baseline score of 3 applies.
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 ('steps out of the current function') and the effect ('pauses at the calling code'), distinguishing it from sibling tools like step_into and step_over.
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?
States when to use it ('to quickly exit a function you've stepped into') and a precondition ('session must be paused'). No explicit when-not or alternatives, but context with siblings provides guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Steps 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.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ID of the debugging session. The session must be paused. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses key behavioral traits: it steps over function calls (executing them without stepping into) and requires a paused session. This gives sufficient transparency for an agent to understand the tool's behavior.
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 two sentences long, front-loads the core action, and avoids unnecessary words. Every sentence adds value without redundancy.
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 one parameter and no output schema, the description covers the essential behavior and context. The sibling tools provide differentiation, and the description is complete enough for an agent to understand when and how to use it.
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 a clear description for 'session_id' that already includes the prerequisite about the session being paused. The tool description does not add additional parameter meaning beyond what the schema provides, so it meets the baseline but does not exceed it.
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 steps over the current statement to the next line in the same function, and distinguishes it from stepping into or out of functions. It uses a specific verb ('steps over') and resource ('current statement'), making its purpose unambiguous.
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 explains when to use it (when debugging and wanting to skip function calls) and notes the prerequisite that the session must be paused. However, it does not explicitly state when not to use it or mention alternatives among siblings.
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.
v1.0.0connect_debuggerdisconnect_debuggerevaluate_expressionget_call_stackget_original_locationget_scope_variablesget_script_sourcelist_breakpointslist_scriptspause_executionremove_breakpointresume_executionset_breakpointset_pause_on_exceptionsset_variable_valuestep_intostep_outstep_overEvery tool has a clearly distinct purpose with no ambiguity. Each tool targets a specific debugging operation (e.g., connect/disconnect, breakpoint management, execution control, variable inspection, source mapping), and descriptions clearly differentiate them. There is no overlap that would cause misselection.
All tool names follow a consistent verb_noun pattern (e.g., connect_debugger, evaluate_expression, set_breakpoint). The naming is uniform throughout, using snake_case and clear action-object pairs, making the set predictable and easy to understand.
With 18 tools, the count is well-scoped for a comprehensive JavaScript debugger. Each tool earns its place by covering essential debugging operations (session management, breakpoints, stepping, variable inspection, source mapping), without being excessive or thin for the domain.
The tool surface provides complete coverage for JavaScript debugging, including session lifecycle (connect/disconnect), breakpoint CRUD, execution control (pause/resume/step), state inspection (variables/call stack/expressions), and source mapping. There are no obvious gaps, enabling full debugging workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Live browser debugging for AI assistants — DOM, console, network via MCP.
A paid remote MCP for AI agent browser DevTools MCP, built to return verdicts, receipts, usage logs,
Shared debugging memory for AI coding agents
Direct access to Cypress tests results and accessibility reports in your AI workflow.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/johngrimes/mcp-js-debugger'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
