MCP Debugger

set_breakpoint

Pause program execution at a specific line, function, or statement to inspect variables and control flow during debugging. Supports conditions and logpoints.

Instructions

Set a breakpoint. Setting breakpoints on non-executable lines (structural, declarative) may lead to unexpected behavior

Input Schema

TableJSON Schema

Name	Required	Description
`file`	No	Path to the source file or Java FQCN. For Java, passing a fully-qualified class name (e.g. "com.example.MyClass" or "com.example.Outer$Inner") is preferred — it works reliably with all classloaders including custom classloaders. Alternatively, use absolute file paths.
`line`	No	Line number where to set breakpoint. Executable statements (assignments, function calls, conditionals, returns) work best. Structural lines (function/class definitions), declarative lines (imports), or non-executable lines (comments, blank lines) may cause unexpected stepping behavior
`function`	No	Address by symbol name instead of file location: break on entry to this function/method (DAP function breakpoint). No file or line needed — names survive edits better than both. Composes with condition only. Supported by Python, Go, Rust, C/C++, .NET, Java, JavaScript and COBOL (paragraph, section or PROGRAM-ID names, e.g. "1000-INIT" or "1000-INIT OF PAYROLL") adapters; not by Ruby (rdbg ignores the request). JavaScript names are dotted runtime paths (e.g. "handler" or "obj.method") bound to the current function value: top-level function declarations of the main module bind at launch; functions in modules loaded later bind at the next pause
`nearLine`	No	With statement only: when the statement text appears on multiple lines, bind to the match closest to this line
`condition`	No	Optional expression: only break (or log) when it evaluates truthy
`sessionId`	Yes
`statement`	No	Address by content instead of line number: the text of the target line, like an Edit-tool match — a distinctive substring is enough (leading/trailing whitespace and trailing //- or #-comments are ignored; an exact whole-line match always wins over substring matches). Preferred over line — it can only land on a line containing your text (an inexact or multi-candidate match adds a warning to the response) and survives file edits across restart_debugging. If the text appears on multiple lines, the error lists every match; add nearLine to pick one. Provide statement OR line, not both
`logMessage`	No	Create a logpoint: instead of pausing, log this message when the line is hit. Expressions in {curly braces} are interpolated (e.g. "order={orderId} total={total}"). Messages arrive in get_output while the program runs at full speed. Supported by the Python, JavaScript, Go, Rust, C/C++, COBOL ({WS-NAME} data references) and mock adapters; not by Java, .NET, or Ruby
`suspendPolicy`	No	Suspend policy when breakpoint is hit: "all" suspends all threads (default), "thread" only suspends the event thread. Only supported by the Java/JDI adapter.
`expectedContent`	No	Optional assertion: text you expect on the target line — a distinctive substring is enough (leading/trailing whitespace and trailing //- or #-comments are ignored). If it does not match, the breakpoint is NOT set and the error shows the actual content of that line and its neighbors — use this to catch stale or off-by-one line numbers before they cause confusing behavior

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.25.1Sep 30, 2026

addedInput schema / properties / condition / description

Added value: +"Optional expression: only break (or log) when it evaluates truthy"

addedInput schema / properties / expectedContent

Added value: +{
+  "description": "Optional assertion: text you expect on the target line — a distinctive substring is enough (leading/trailing whitespace and trailing //- or #-comments are ignored). If it does not match, the breakpoint is NOT set and the error shows the actual content of that line and its neighbors — use this to catch stale or off-by-one line numbers before they cause confusing behavior",
+  "type": "string"
+}

addedInput schema / properties / function

Added value: +{
+  "description": "Address by symbol name instead of file location: break on entry to this function/method (DAP function breakpoint). No file or line needed — names survive edits better than both. Composes with condition only. Supported by Python, Go, Rust, C/C++, .NET, Java, JavaScript and COBOL (paragraph, section or PROGRAM-ID names, e.g. \"1000-INIT\" or \"1000-INIT OF PAYROLL\") adapters; not by Ruby (rdbg ignores the request). JavaScript names are dotted runtime paths (e.g. \"handler\" or \"obj.method\") bound to the current function value: top-level function declarations of the main module bind at launch; functions in modules loaded later bind at the next pause",
+  "type": "string"
+}

addedInput schema / properties / logMessage

Added value: +{
+  "description": "Create a logpoint: instead of pausing, log this message when the line is hit. Expressions in {curly braces} are interpolated (e.g. \"order={orderId} total={total}\"). Messages arrive in get_output while the program runs at full speed. Supported by the Python, JavaScript, Go, Rust, C/C++, COBOL ({WS-NAME} data references) and mock adapters; not by Java, .NET, or Ruby",
+  "type": "string"
+}

addedInput schema / properties / nearLine

Added value: +{
+  "description": "With statement only: when the statement text appears on multiple lines, bind to the match closest to this line",
+  "type": "number"
+}

addedInput schema / properties / statement

Added value: +{
+  "description": "Address by content instead of line number: the text of the target line, like an Edit-tool match — a distinctive substring is enough (leading/trailing whitespace and trailing //- or #-comments are ignored; an exact whole-line match always wins over substring matches). Preferred over line — it can only land on a line containing your text (an inexact or multi-candidate match adds a warning to the response) and survives file edits across restart_debugging. If the text appears on multiple lines, the error lists every match; add nearLine to pick one. Provide statement OR line, not both",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "sessionId",
-  "file",
-  "line"
-]New value: +[
+  "sessionId"
+]

Changed2 schema fields changedv0.20.0May 4, 2026

changedInput schema / properties / file / description

Previous value: -"Path to the source file. Use absolute paths or paths relative to your current working directory"New value: +"Path to the source file or Java FQCN. For Java, passing a fully-qualified class name (e.g. \"com.example.MyClass\" or \"com.example.Outer$Inner\") is preferred — it works reliably with all classloaders including custom classloaders. Alternatively, use absolute file paths."

addedInput schema / properties / suspendPolicy

Added value: +{
+  "description": "Suspend policy when breakpoint is hit: \"all\" suspends all threads (default), \"thread\" only suspends the event thread. Only supported by the Java/JDI adapter.",
+  "enum": [
+    "all",
+    "thread"
+  ],
+  "type": "string"
+}

First observedDec 29, 2025

TDQS

B3.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full disclosure burden, and it does volunteer one real behavioral trait: breakpoints on structural/declarative lines cause unexpected stepping behavior. Beyond that caveat it says nothing about idempotency, persistence across restart_debugging, permission needs, or what the response contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, zero filler, and the core action is front-loaded ahead of the hazard warning. It is arguably too terse for a 10-parameter tool, which keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter mutation-adjacent tool with no annotations and no output schema, the description covers only one hazard. It omits session prerequisites, whether breakpoints persist, and what a successful call returns or how failures are reported.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 90%, so the schema already documents all 10 parameters in detail (statement, function, logMessage, expectedContent, suspendPolicy, etc.). The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource ("Set a breakpoint"), which cleanly separates it from siblings like remove_breakpoint, clear_breakpoints, and list_breakpoints. It does not explicitly differentiate itself from create_debug_session or explain the line/function/statement addressing modes, but the core action is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The caveat about non-executable lines functions as an implicit "when not to / watch out" rule, so usage is implied rather than stated. There is no guidance on prerequisites (an active session), no mention of alternatives such as condition vs logMessage vs suspendPolicy, and no explicit routing against sibling breakpoint tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_breakpoint

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools