This server is an MCP bridge that gives coding agents (like Qwen Code) native debugger capabilities via DAP, enabling live debugging, crash analysis, and bounded autonomous fix/verify loops.
Autonomous crash debugging: run the debug_this_crash workflow to diagnose, propose fixes, apply them (via external tools), rebuild, reproduce, and verify outcomes with statuses like fixed, retry-fix, or budget-exhausted.
Launch/attach debuggers: start CodeLLDB or any local DAP adapter, launch or attach to native processes, and configure breakpoints (source, function, instruction, data, exception).
Inspect runtime state: list threads, read stack traces, scopes, variables, evaluate expressions, list modules, disassemble memory, read memory, and fetch exception info.
Control execution: pause, continue, step over/into/out, and wait for stops.
Analyze crashes: open minidumps (read-only postmort), classify crashes, score project frames, correlate operands/registers/locals, root causes, and compute verification fingerprints.- Capture snap: gather a bounded runtime snapshot (stop reason, stack locals, registers, disassembly, modules, exception info) for agent reasoning.
**Manage sessions check status, review recent DAP events, and disconnectly.
Safety-focused: only local stdio transport, no shell or source-writing primitives bounded memory/stack reads, and no hidden autonomous state.
Provides integration with LLVM's lldb-dap debugger adapter for native runtime debugging, live launch/attach workflows, and read-only core-file/minidump analysis, enabling stack, register, local variable, exception, module, disassembly, memory, and source-correlation evidence collection for crash diagnosis and bounded autonomous fix/verify cycles.
Click on "Deploy 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., "@qwen-dap-mcp Launch the C++ binary, set a breakpoint at main, and take a debug snapshot"
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.
Give coding agents a real native debugger.
qwen-dap-mcp is a local Debug Adapter Protocol (DAP) → Model Context Protocol (MCP) bridge for native crash debugging, hang/deadlock triage, crash dumps, differential runtime analysis, remote targets, and bounded fix/verify workflows.
Built for Qwen Code, usable from any stdio MCP client, and designed to expose debugger evidence without turning MCP into a general-purpose shell.
Quick start · Capabilities · Debugger support · Safety · Docs · Contributing
Coding agents can read source and propose patches, but native failures often cannot be diagnosed reliably from source alone. The useful evidence lives at runtime: thread stacks, registers, locals, disassembly, exception state, modules, memory, wait states, symbols, and crash dumps.
qwen-dap-mcp makes that evidence available through MCP and adds agent-oriented workflows on top of raw debugger primitives:
Evidence first — inspect the actual failing process instead of guessing from source.
High-level workflows — crash, hang, differential, writer-tracing, dump, and verification tools are designed for agents rather than humans driving a debugger console.
Bounded automation — autonomous fix/verify state is explicit, serializable, iteration-limited, and re-checks the original reproduction.
Small default surface — the normal agent toolset stays compact while advanced low-level DAP tools remain opt-in.
Local by default — the MCP server communicates over stdio and debugger adapters run locally unless you explicitly configure a validated remote target.
Related MCP server: DebugPilot
Install directly from GitHub:
qwen extensions install SLP-DEV1/qwen-dap-mcpOr install the published npm package:
qwen extensions install @slp-dev1/qwen-dap-mcpThen verify the extension:
/mcp
/skillsYou should see the qwen-dap-mcp server and the bundled native-runtime-debug skill.
npx -y @slp-dev1/qwen-dap-mcpTypical configuration:
{
"mcpServers": {
"qwen-dap-mcp": {
"command": "npx",
"args": ["-y", "@slp-dev1/qwen-dap-mcp"]
}
}
}CLI discovery is available without starting the stdio server:
qwen-dap-mcp --help
qwen-dap-mcp --versionYou: Debug why app.exe crashes with --repro
Coding agent
↓
qwen-dap-mcp starts a DAP debugger
↓
captures the native failure + project-controlled frame
↓
correlates stack + registers + locals + disassembly
↓
backtracks runtime evidence toward the likely producer
↓
agent applies a minimal source fix
↓
builds and repeats the original reproduction
↓
verifies whether the original crash fingerprint is goneThe MCP server supplies debugger evidence and bounded workflow state. Source editing, builds, tests, and source-control operations stay with the coding agent's normal authorized tools.
Problem | Agent-oriented capability |
Native crash | Diagnose a stopped process, identify project frames, collect runtime evidence, and drive bounded fix/verify loops |
Hang or deadlock | Observe, pause when needed, capture all-thread stacks, classify waits, and surface conservative deadlock candidates |
Good run vs bad run | Compare stopped sessions semantically while suppressing raw ASLR/address noise |
Suspicious value | Trace real writers with data breakpoints/watchpoints and bounded temporal tracing |
Crash dump | Inspect Windows minidumps and supported LLDB/GDB postmortem targets without launching the failed program |
Remote native target | Attach through validated |
Multiple targets | Keep isolated DAP sessions and route requests by |
Agent safety | Keep the default surface compact and optionally gate executable/mutating DAP actions with HOL Guard |
The default toolset intentionally exposes 14 high-signal tools:
Tool | Purpose |
| High-level native crash diagnosis and bounded autonomous verification |
| High-level hang/deadlock triage |
| Semantic comparison of baseline and failing stopped sessions |
| Bounded temporal tracing of a suspicious value |
| Diagnose the current debugger stop |
| Correlate source with nearby native instructions |
| Stop at the code that writes a watched value |
| Continue/launch toward a bounded meaningful stop |
| Open supported postmortem dump/core targets |
| Capture structured runtime evidence |
| Inspect debugger/session state |
| Continue the active target |
| Cleanly end a debugger session |
| Create, inspect, and remove isolated sessions |
Need raw stacks, scopes, variables, memory, modules, breakpoints, evaluation, stepping, or adapter-specific controls? See the opt-in full toolset in docs/toolsets.md.
Adapter / target | Supported use |
CodeLLDB | Local native launch/attach and Windows minidump workflows |
LLVM | Native launch/attach, core-file inspection, and |
GNU GDB 14+ DAP | Native launch/attach, core-file workflows, and hardened |
Adapter discovery, prerequisites, and platform-specific setup are documented in docs/README.md.
Raw DAP is intentionally low level. qwen-dap-mcp keeps raw debugger access available in the full toolset, but its default surface focuses on workflows an agent can reason about directly.
Source only | Raw DAP | qwen-dap-mcp agent tools | |
Runtime debugger evidence | — | ✓ | ✓ |
High-level crash diagnosis | — | — | ✓ |
All-thread hang triage | — | manual | ✓ |
Good-vs-bad semantic diff | — | manual | ✓ |
Explicit bounded fix/verify state | — | — | ✓ |
Verification fingerprinting | — | — | ✓ |
A debugger can execute and mutate target state, so the bridge treats that power explicitly.
No arbitrary shell tool is exposed by the MCP server.
No source-writing primitive is exposed by the MCP server.
No general memory-write primitive is part of the default agent surface.
Remote endpoints are validated and non-loopback access requires explicit allowlisting.
Autonomous workflow state is explicit rather than hidden inside a background loop.
Optional HOL Guard 2.2+ integration can fail closed before protected adapter startup or executable/mutating DAP actions cross the debugger boundary.
Read the full policy and threat model in docs/hol-guard.md and SECURITY.md.
The repository includes deterministic native fixtures so behavior can be tested instead of demonstrated only with screenshots:
npm run demo:build -- null-pointer
npm run demo:repro -- null-pointer
npm run demo:hang:build -- deadlock
npm run demo:hang:repro -- deadlockbenchmark/ also contains a reproducible comparison harness for source-only, dap-raw, and qwen-dap-mcp workflows. It deliberately ships without invented performance numbers; publishable results should record the exact model, settings, commit, reproduction, raw outcome, and verification status.
Start with the documentation index.
Topic | Guide |
CodeLLDB on Windows | |
LLVM | |
GNU GDB DAP | |
Remote debugging | |
Hang/deadlock analysis | |
Differential debugging | |
Agent vs full toolsets | |
HOL Guard integration | |
Publishing / releases |
Requirements: Node.js 20+.
git clone https://github.com/SLP-DEV1/qwen-dap-mcp.git
cd qwen-dap-mcp
npm ci
npm run checknpm run check builds TypeScript, runs the test suite, and validates the self-contained Qwen extension package. CI additionally exercises native crash/hang fixtures, adapter-specific real smoke tests, package output, HOL Guard compatibility, and the container build.
See CONTRIBUTING.md before opening a pull request.
Published as:
npm: @slp-dev1/qwen-dap-mcp
MCP Registry: io.github.SLP-DEV1/qwen-dap-mcp
Qwen Code extension: qwen extensions install SLP-DEV1/qwen-dap-mcp
GitHub Releases: self-contained extension archives
Current release details are in CHANGELOG.md and GitHub Releases.
Bug reports, reproducible native failure cases, adapter compatibility findings, documentation fixes, and focused feature proposals are welcome. Please keep additions evidence-driven and prefer high-level agent workflows over expanding the default surface with raw debugger commands.
If this project saves you a debugging session, consider starring the repository — it helps other MCP and coding-agent users discover it.
Compare bounded runtime evidence from two existing stopped DAP sessions. Use this for baseline or known-good versus candidate or failing differential debugging after both sessions have reached comparable stops. It compares stack identities, locals, registers, exception state, symbol health, and modules semantically; non-null raw address-only changes are marked unstable rather than causal evidence. Do not use it to launch, resume, or alter either target; prepare both runtime states with the normal lifecycle tools first.
| Name | Required | Description | Default |
|---|---|---|---|
| snapshot | No | Bounded evidence capture settings applied independently to both sessions. | |
| timeoutMs | No | Aggregate deadline for collecting both snapshots. Cancellation propagates to pending DAP requests/event waits in this operation context. | |
| baselineSessionId | Yes | Session representing the known-good or baseline runtime state. | |
| candidateSessionId | Yes | Session representing the failing or changed runtime state. |
| Name | Required | Description |
|---|---|---|
| diff | Yes | |
| baseline | Yes | |
| guidance | Yes | |
| candidate | Yes | |
| evidenceBudget | Yes | |
| baselineSessionId | Yes | |
| candidateSessionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the readOnly/idempotent/non-destructive annotations: it discloses that comparison is semantic, that stack/locals/registers/exception/symbol/module evidence is compared, and that 'non-null raw address-only changes are marked unstable rather than causal evidence.' This tells the agent how results should be interpreted and reinforces that the tool observes rather than mutates sessions.
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 three focused sentences. The first states purpose, the second gives usage context and the comparative scope, and the third provides an exclusion and directs preparation. Every sentence earns its place with no repetition of schema or annotation 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?
Given the rich input schema, output schema, and annotations, this description is complete for safe and correct invocation. It covers when to use, what is compared, how unstable address-only changes are treated, and what the tool must not be used for. No critical operational knowledge is missing.
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%, with both required session parameters and the nested snapshot object clearly documented. The prose description adds contextual framing but does not materially expand on the parameter meaning already present in the schema, so it stays at the baseline for high-coverage schemas.
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 opens with a specific verb and resource: 'Compare bounded runtime evidence from two existing stopped DAP sessions.' It then distinguishes the tool from single-session diagnostics by framing it for 'baseline or known-good versus candidate or failing differential debugging,' which cleanly separates it from sibling tools like debug_snapshot and debug_diagnose_stop.
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 states when to use the tool: for differential debugging 'after both sessions have reached comparable stops.' It also gives clear when-not guidance: 'Do not use it to launch, resume, or alter either target; prepare both runtime states with the normal lifecycle tools first.' This directs the agent to alternative lifecycle tooling without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resume one paused thread in a live debug session. Use this after inspecting a stopped state when execution should proceed to the next stop or termination; do not use it for crash dumps because postmortem targets cannot resume. This changes debuggee execution state and may allow the target to perform normal application side effects before the next stop.
| Name | Required | Description | Default |
|---|---|---|---|
| threadId | Yes | DAP thread identifier to resume; obtain it from debug_snapshot, debug_status, or a stopped event. | |
| sessionId | No | Optional DAP session ID. Omit to use the backward-compatible default session. | |
| timeoutMs | No | Maximum time in milliseconds to wait for the next stopped event when waitForStop is true. | |
| waitForStop | No | When true, wait for the next stopped event before returning; when false, return after the continue request is accepted. |
| Name | Required | Description |
|---|---|---|
| stopped | No | |
| response | No | |
| allThreadsContinued | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive and non-read-only, and the description reinforces this by disclosing that continuing can change debuggee execution state and allow normal application side effects before the next stop. This is exactly the kind of behavioral context that annotations alone do not provide.
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?
Three sentences, each with a distinct job: state the action, give usage rules, and warn of side effects. The core purpose is front-loaded and there is no redundant or filler prose.
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 an output schema exists, return values need no explanation in the description. The description covers the live-session constraint, the postmortem exclusion, and the side-effect risk, leaving only details already present in the schema.
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 baseline is 3. The description adds little parameter-specific meaning—it only reinforces that exactly one thread is resumed, while all parameter details already live in 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 first sentence states a specific verb and resource: resume one paused thread in a live debug session. It also explicitly excludes crash dumps, which distinguishes it from sibling dump-analysis tools without needing to open their schemas.
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 clearly says when to use it ('after inspecting a stopped state when execution should proceed to the next stop or termination') and when not to use it ('do not use it for crash dumps'). However, it does not name an alternative tool to use for crash dumps, so the routing guidance stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Diagnose an already stopped live or postmortem debug session without changing execution state. Use this when a debugger has captured the failure and you want project-frame selection, crash classification, operand/register/variable bindings, call-chain provenance, ranked hypotheses, and a fix/rebuild/reproduce/verify plan; use debug_snapshot instead when only raw evidence is needed. The tool is read-only and returns both the bounded snapshot and the derived diagnosis, including collection limitations when optional debugger evidence is unavailable.
| Name | Required | Description | Default |
|---|---|---|---|
| analysis | No | Hints used to distinguish project code from runtime, system, or third-party frames. | |
| threadId | No | Stopped DAP thread to inspect; omit to use the session-selected stopped thread. | |
| sessionId | No | Optional DAP session ID. Omit to use the backward-compatible default session. | |
| moduleCount | No | Maximum loaded modules to include when module collection is enabled. | |
| stackLevels | No | Maximum number of stack frames to inspect when collecting crash evidence. | |
| includeModules | No | Include a bounded list of loaded executable images and libraries. | |
| disassembleAfter | No | Number of instructions after the selected instruction to request. | |
| disassembleBefore | No | Number of instructions before the selected instruction to request. | |
| includeDisassembly | No | Include best-effort disassembly around the selected instruction pointer when supported. | |
| includeExceptionInfo | No | Request structured exception information for the stopped thread when supported. | |
| maxVariablesPerScope | No | Maximum variables returned per inspected scope, bounding evidence size. |
| Name | Required | Description |
|---|---|---|
| snapshot | Yes | |
| diagnosis | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the bar is lower. The description adds value beyond those by stating that it 'does not change execution state', that it returns both a bounded snapshot and a derived diagnosis, and that it discloses collection limitations when optional debugger evidence is unavailable. This gives useful behavioral context beyond the structured annotations.
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 dense but tightly structured: it front-loads the core purpose, lists the derived outputs, routes to the sibling alternative, and closes with read-only behavior and output scope. Every clause contributes, and there is no redundant repetition of the tool name or schema contents.
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 tool with 11 parameters, nested objects, no required parameters, and an output schema, the description covers the key operational context: the precondition ('already stopped'), the read-only guarantee, the distinction from debug_snapshot, and the bounded/limited nature of results. It does not enumerate parameter details, but the input schema fully covers those, so the description is sufficiently 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 the schema already documents every parameter in detail. The description does not add parameter-specific semantics, but it does contextualize the optional evidence gathering and bounded results, which relates to the parameters. Baseline 3 is appropriate because the schema carries the parameter documentation burden.
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 names a specific verb ('Diagnose'), a precise resource ('already stopped live or postmortem debug session'), and a concrete set of outputs (project-frame selection, crash classification, bindings, provenance, ranked hypotheses, fix plan). It also explicitly differentiates itself from debug_snapshot, so an agent can distinguish it from siblings without opening schemas.
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 a clear when-to-use condition ('when a debugger has captured the failure and you want...') and names the alternative (debug_snapshot) with the condition that selects it ('when only raw evidence is needed'). This is explicit routing guidance rather than leaving the choice to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
End the active DAP session and stop its local adapter process. Use this when debugging is finished or the session must be reset; do not call it when more runtime evidence is still needed. With terminateDebuggee=true it may also terminate a live target process, so this operation can destroy the current runtime state and cannot be treated as read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | No | Optional DAP session ID. Omit to use the backward-compatible default session. | |
| terminateDebuggee | No | Whether the debugger should terminate the live debuggee while disconnecting; set false to request detach/preserve behavior when the adapter supports it. |
| Name | Required | Description |
|---|---|---|
| disconnected | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive, but the description adds valuable context: it ends the session, stops the adapter process, may terminate a live target with terminateDebuggee=true, and explicitly warns that runtime state can be destroyed. This meaningfully exceeds the annotation signal.
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?
Three sentences, each earning its place: the first states the core operation, the second provides usage guidance, and the third warns about destructive behavior. No filler or redundant restatement.
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 two well-documented optional parameters, an output schema, and annotations already covering safety traits, the description covers purpose, appropriate usage, and destructive consequences. Nothing needed to invoke the tool correctly is missing.
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 both parameters are already documented. The description adds some interpretation around terminateDebuggee's destructive potential, but the schema already explains the detach/preserve behavior, so the description provides only marginal added value.
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 a specific verb ('End') and resource ('active DAP session') plus the local adapter process, making the operation's scope unambiguous. It is clearly distinct from siblings like debug_continue or debug_snapshot even without naming them.
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 explicit when-to-use and when-not-to-use guidance: use when debugging is finished or must be reset, and do not call when more runtime evidence is needed. It does not name an alternative tool, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Temporarily watch a variable or debugger expression, resume an authorized live target, and capture the first resulting stop to identify the immediate writer candidate. Use this after a stopped-state diagnosis suggests a value was corrupted and runtime provenance is needed; do not use it for crash dumps or when resuming is unsafe. Adapters with DAP data-breakpoint support use that protocol directly; GDB 14/15 uses a bounded watch/rwatch/awatch command through DAP REPL because those releases do not advertise native data breakpoints. The tool removes only the temporary watch it created and never automatically continues through an unrelated stop.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Variable child name or debugger expression to watch. Without variablesReference, the expression is resolved in frameId/current frame when supported. GDB fallback expressions must not contain control characters or line breaks. | |
| frameId | No | Optional stopped frame used to resolve an expression; omit to use the current snapshot frame. Ignored by native DAP child resolution when variablesReference is supplied. | |
| snapshot | No | Bounds for the evidence snapshot captured after execution stops. | |
| threadId | No | Stopped thread to resume and inspect; omit to use the debugger-selected stopped thread. | |
| condition | No | Optional adapter-supported condition for native DAP data breakpoints. Intentionally rejected by the bounded GDB fallback. | |
| sessionId | No | Optional DAP session ID. Omit to use the backward-compatible default session. | |
| timeoutMs | No | Maximum time in milliseconds to wait for a stop, exit, or termination after resuming. | |
| accessType | No | Requested watchpoint access mode. write is the normal choice when finding who corrupts a value; GDB maps these to watch/rwatch/awatch. | write |
| hitCondition | No | Optional adapter-supported hit-count condition for native DAP data breakpoints. Intentionally rejected by the bounded GDB fallback. | |
| variablesReference | No | Optional DAP variable-container reference when the adapter advertises native data breakpoints. Omit for the GDB watch-command fallback and pass a debugger-visible expression in name instead. | |
| replaceExistingDataBreakpoints | No | For native DAP data breakpoints, temporarily replace existing MCP-managed watches when true. The GDB fallback never deletes unrelated CLI watchpoints and only removes its own temporary watch. |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| before | Yes | |
| status | Yes | |
| outcome | Yes | |
| guidance | Yes | |
| snapshot | No | |
| strategy | Yes | |
| installed | Yes | |
| resolution | Yes | |
| writerFrame | No | |
| hitConfirmed | Yes | |
| cleanupWarning | No | |
| writerCorrelation | No | |
| priorDataBreakpointCount | Yes | |
| replaceExistingDataBreakpoints | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by explaining that the tool temporarily creates a watch, removes only that watch, never automatically continues through unrelated stops, and uses different mechanisms for DAP vs GDB 14/15. This gives the agent a clear model of side effects and safety boundaries.
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 three sentences with no filler: the first front-loads the core action, the second gives usage boundaries, and the third explains protocol behavior and cleanup guarantees. Every sentence adds distinct, necessary 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?
The description is complete for a complex tool with 11 parameters: it covers purpose, safe usage, exclusions, protocol differences, cleanup behavior, and the nature of the resulting stop. The schema and output schema fill in remaining structured details, leaving no critical gap for an agent deciding whether and how to call 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%, so the schema already documents all parameter meanings. The description adds protocol-level context such as DAP vs GDB behavior and the bounded watch fallback, but most individual parameter semantics are already fully captured in the input schema itself.
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 a specific action chain: temporarily watch a variable/expression, resume the target, and capture the first stop to identify the immediate writer candidate. It clearly distinguishes this from sibling tools by framing it as the corruption-provenance diagnostic and explicitly separating it from crash-dump use.
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 gives explicit when-to-use guidance: after a stopped-state diagnosis suggests corruption and runtime provenance is needed. It also provides explicit when-not-to-use guidance: not for crash dumps or when resuming is unsafe, though it does not name a specific sibling alternative to use instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a local native core/minidump with CodeLLDB, upstream LLVM lldb-dap, or GNU GDB DAP and capture bounded postmortem evidence. Use this when the failure is already recorded and no target process should execute; use debug_run_to_stop or debug_this_crash for a live reproduction instead. The tool starts only the selected local debugger adapter, never launches or resumes the crashed program, treats the dump as read-only, and returns the initial stack/locals/registers plus optional modules and disassembly.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Working directory for the local debugger adapter process; this does not execute the crashed target. | |
| adapter | No | Debugger adapter used for postmortem inspection. lldb-dap and gdb use their native coreFile attach semantics. | codelldb |
| program | No | Path to the matching executable image. Optional for CodeLLDB/GDB, but required when adapter=lldb-dap because LLVM coreFile loading binds the dump to its program image. | |
| dumpPath | Yes | Absolute or local path to the native core/minidump file to inspect. | |
| threadId | No | Specific dump thread to inspect; omit to use the debugger-selected stopped/crashed thread. | |
| sessionId | No | Optional DAP session ID. Omit to use the backward-compatible default session. | |
| sourceMap | No | Optional mapping from source paths recorded in symbols to local source paths. Supported by CodeLLDB/lldb-dap; GDB currently rejects this field rather than guessing undocumented semantics. | |
| adapterPath | No | Optional explicit executable path for the selected debugger adapter; omit to use its normal discovery logic. | |
| moduleCount | No | Maximum number of modules to include when includeModules is true. | |
| stackLevels | No | Maximum stack frames to include in the initial postmortem snapshot. | |
| includeModules | No | Include loaded executable images and libraries recorded in the dump. | |
| requestTimeoutMs | No | Per-request DAP timeout in milliseconds while opening and inspecting the dump. | |
| includeDisassembly | No | Include best-effort instructions around the selected crash frame. | |
| maxVariablesPerScope | No | Maximum variables returned per scope in the initial snapshot. |
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| attach | Yes | |
| adapter | Yes | |
| program | No | |
| dumpPath | Yes | |
| guidance | Yes | |
| snapshot | Yes | |
| adapterKind | Yes | |
| capabilities | Yes | |
| readOnlyTarget | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral context beyond the annotations: it starts only the debugger adapter, never launches or resumes the crashed program, treats the dump as read-only, and returns a bounded initial snapshot. This complements the readOnlyHint/idempotentHint annotations and gives the agent a clear safety profile.
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 compact and front-loaded: the action comes first, followed by usage context, safety behavior, and return scope. Every sentence earns its place with no filler or 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 14-parameter tool, the description covers the key decision points: when to use it, what it does not do, what it returns, and how it differs from live-debugging siblings. The output schema and rich input schema cover the remaining detail, so nothing essential is missing.
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 documents every parameter in detail. The description adds some high-level context about adapters, modules, and disassembly, but it does not substantially go beyond what the input schema already provides.
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 specific action: opening a local core/minidump with a local debugger adapter and capturing bounded postmortem evidence. It also explicitly distinguishes this tool from live-debugging siblings like debug_run_to_stop and debug_this_crash, so an agent can select it confidently.
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 explicit when-to-use guidance: use it when the failure is already recorded and no target process should execute. It also names alternatives for live reproduction, leaving no ambiguity about when this tool is appropriate versus its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run one live launch or attach through an already initialized DAP adapter until the first stopped, exited, or terminated event. Use this when you need deterministic runtime evidence from a reproduction; do not use it for a postmortem dump or when executing/attaching to the local target is not authorized. Launch mode executes application code and attach mode changes debugger control of an existing process, so normal target side effects may occur before the stop. Returns the request result, terminal/stopped outcome, session status, and a bounded snapshot only when a stopped event is captured.
| Name | Required | Description | Default |
|---|---|---|---|
| request | No | Choose launch to start a new target from configuration, or attach to connect to an existing authorized local target. | launch |
| snapshot | No | Optional bounds and evidence categories for the snapshot captured only when execution stops. | |
| sessionId | No | Optional DAP session ID. Omit to use the backward-compatible default session. | |
| timeoutMs | No | Maximum milliseconds to wait for the first stopped, exited, or terminated event. | |
| breakpoints | No | Optional source breakpoint groups configured before the debugger completes launch/attach setup. | |
| configuration | Yes | Adapter-specific DAP launch or attach configuration. |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| outcome | Yes | |
| request | Yes | |
| snapshot | No | |
| requestResult | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses target side effects beyond what annotations state: 'normal target side effects may occur before the stop,' and it explains the difference between launch and attach behavior. It also sets a boundary on the snapshot ('bounded snapshot only when a stopped event is captured') and states the 'already initialized DAP adapter' prerequisite. This aligns with and enriches the destructiveHint=true annotation.
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?
Four sentences, each earning its place: core action, selection guidance, side-effect warning, and return summary. The most important information is front-loaded before the exclusion and return-value details.
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 tool with 6 parameters, nested schema, and an output schema, the description covers the action, prerequisites, side effects, return categories, and exclusions. Missing details such as individual parameter bounds are already covered by the schema, so no critical selection or invocation context is absent.
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 description coverage, the schema already documents the parameters, so the baseline is 3. The description adds operational meaning for the request parameter (launch executes code, attach changes debugger control) and clarifies that snapshots are only produced on a stopped event, which is useful beyond the raw 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 states a specific action ('Run one live launch or attach... until the first stopped, exited, or terminated event'), identifies the resource (already initialized DAP adapter), and scopes the use case to deterministic runtime evidence. It clearly contrasts with postmortem dumps, distinguishing it from sibling debug_open_dump.
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 explicitly says when to use ('when you need deterministic runtime evidence from a reproduction') and when not to use ('do not use it for a postmortem dump or when executing/attaching to the local target is not authorized'). It does not name a specific alternative tool, but the postmortem exclusion effectively routes the agent away from debug_open_dump.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this tool to list, create, or close isolated DAP sessions before routing other debugger tools with sessionId. Omit sessionId on normal debug tools only when the backward-compatible default session is intended; do not use a global session selector for concurrent work.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | Management action: list current sessions, create a new isolated session, or close one session. | list |
| sessionId | No | Requested ID for create, or target ID for close. Omit on create to generate a bounded session-N identifier. | |
| terminateDebuggee | No | For close only: request debugger termination of the live target before resetting/removing the session. |
| Name | Required | Description |
|---|---|---|
| action | Yes | |
| removed | No | |
| sessions | Yes | |
| sessionId | No | |
| maxSessions | Yes | |
| defaultSessionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=false and destructiveHint=true, so the description does not need to restate mutation/destruction. It adds useful behavioral context about session isolation and default-session backward compatibility. It does not spell out that closing can terminate the debuggee, but the schema's terminateDebuggee parameter covers that detail.
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 tight sentences with no filler. The first sentence names the actions and context; the second adds the critical sessionId routing caveat. Every clause 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 100% schema coverage, an output schema, and annotations covering the destructive profile, the description is sufficient for an agent to select and invoke the tool correctly. The only behaviors not described in prose are already captured in the structured fields.
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%, with meaningful descriptions for action, sessionId, and terminateDebuggee. The tool description adds routing context but no new parameter-level semantics, so the baseline of 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 states a specific verb set ('list, create, or close'), a specific resource ('isolated DAP sessions'), and positions the tool as the session-lifecycle manager that must be used before routing other debugger tools. This clearly distinguishes it from sibling debugger tools like debug_continue or debug_source_disassembly.
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 when to use the tool (managing DAP sessions before other tools), and gives concrete exclusion guidance: omit sessionId only for the backward-compatible default session and avoid a global session selector for concurrent work. The description tells the agent how to route between this and the other debug tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture bounded evidence from the current stopped debug state without resuming execution. Use this when an agent needs raw stack, locals, registers, exception details, modules, or nearby instructions; prefer debug_diagnose_stop when you also want ranked crash hypotheses and project-frame selection. This is read-only with respect to the debuggee and returns best-effort evidence plus collection errors for optional data that an adapter cannot provide.
| Name | Required | Description | Default |
|---|---|---|---|
| threadId | No | Stopped DAP thread to inspect; omit to use the session-selected stopped thread. | |
| sessionId | No | Optional DAP session ID. Omit to use the backward-compatible default session. | |
| moduleCount | No | Maximum loaded modules to return when includeModules is true. | |
| stackLevels | No | Maximum number of stack frames to include, from the selected thread top downward. | |
| includeModules | No | Include a bounded list of loaded executable images and libraries. | |
| disassembleAfter | No | Number of instructions after the current instruction to request when disassembly is enabled. | |
| disassembleBefore | No | Number of instructions before the current instruction to request when disassembly is enabled. | |
| includeDisassembly | No | Include best-effort instructions around the selected frame instruction pointer when supported. | |
| includeExceptionInfo | No | Include structured exception information for the stopped thread when the adapter supports it. | |
| maxVariablesPerScope | No | Maximum variables returned per inspected scope, bounding output size. |
| Name | Required | Description |
|---|---|---|
| frame | Yes | |
| stack | Yes | |
| locals | Yes | |
| scopes | Yes | |
| thread | Yes | |
| modules | No | |
| stopped | No | |
| exception | No | |
| registers | Yes | |
| postmortem | No | |
| disassembly | No | |
| symbolHealth | Yes | |
| collectionErrors | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, but the description adds meaningful behavioral context: it is read-only with respect to the debuggee, returns best-effort evidence, and includes collection errors for optional data an adapter cannot provide. This clarifies failure behavior and optionality beyond what annotations express.
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?
Three sentences with no wasted words: the first states the core action and constraint, the second gives usage routing, and the third discloses read-only, best-effort, and error behavior. Information is front-loaded and every sentence 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?
For a tool with 10 optional parameters and an output schema, the description covers the essential decision factors: what it returns, when to use it versus the closest sibling, that it is read-only, and how optional failures are reported. Return-value details are rightfully left to the output schema.
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 carries full parameter documentation. The description adds conceptual grouping by naming the kinds of evidence collected (stack, locals, registers, exception details, modules, nearby instructions), which maps to several parameters, but it does not add per-parameter semantics 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?
States a specific verb ('Capture'), a specific resource ('bounded evidence from the current stopped debug state'), and a key constraint ('without resuming execution'). It also distinguishes itself from debug_diagnose_stop by describing the division of labor, so an agent can tell them apart without inspecting schemas.
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?
Explicitly states when to use: when raw stack, locals, registers, exception details, modules, or nearby instructions are needed. It also names the alternative (debug_diagnose_stop) and gives the condition that should route to that sibling (ranked crash hypotheses and project-frame selection). No inference is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Correlate source locations, disassembly, registers, and pointer-like locals for the raw fault frame and the first likely project-controlled frame. Use this for low-level root-cause evidence when a crash is already stopped and instruction/operand provenance matters; prefer debug_diagnose_stop for a broader ranked diagnosis. This is read-only, does not resume the target, and returns frame-selection reasoning, both correlations, operand bindings, and any best-effort collection errors.
| Name | Required | Description | Default |
|---|---|---|---|
| analysis | No | Hints used to distinguish project code from runtime, system, or third-party frames. | |
| threadId | No | Stopped DAP thread to inspect; omit to use the session-selected stopped thread. | |
| sessionId | No | Optional DAP session ID. Omit to use the backward-compatible default session. | |
| stackLevels | No | Maximum stack frames considered while selecting the project-controlled frame. | |
| disassembleAfter | No | Instructions after the selected instruction included in each disassembly window. | |
| disassembleBefore | No | Instructions before the selected instruction included in each disassembly window. |
| Name | Required | Description |
|---|---|---|
| projectFrame | Yes | |
| frameSelection | Yes | |
| operandAnalysis | Yes | |
| collectionErrors | No | |
| faultCorrelation | Yes | |
| projectCorrelation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, but the description adds meaningful behavior beyond that: it explicitly states the tool does not resume the target and describes what it returns, including frame-selection reasoning, correlations, operand bindings, and best-effort collection errors. No contradiction with annotations.
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?
Three sentences pack the core action, usage conditions, explicit alternative, side-effect guarantee, and return-value summary with no filler. The most differentiating information is front-loaded, and every sentence 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?
The description is complete for an agent deciding whether and how to invoke this tool: it gives scope, use context, a sibling alternative, side-effect safety, and an outline of the return payload. Since an output schema exists, detailed return documentation is not required here.
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 input schema fully documents all six parameters. The description itself adds little parameter-level semantics, but that is acceptable because the schema carries the weight; the baseline 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 names a specific verb ('Correlate'), a precise resource set (source locations, disassembly, registers, pointer-like locals), and the frames involved (raw fault frame and first likely project-controlled frame). It explicitly distinguishes itself from debug_diagnose_stop, making the tool's niche clear.
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 second sentence states exactly when to use this tool ('when a crash is already stopped and instruction/operand provenance matters') and names the preferred alternative for broader ranked diagnosis ('prefer debug_diagnose_stop'). This is explicit routing guidance with both inclusion and exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect debugger lifecycle state, the selected stop, recent DAP events, and bounded adapter stderr without changing target execution. Use this to determine whether a session is initialized, running, stopped, postmortem, exited, or failed before choosing another debug tool; it is diagnostic only and does not resume, launch, attach, or terminate the debuggee.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| adapterId | No | |
| adapterPid | No | |
| configured | Yes | |
| initialized | Yes | |
| capabilities | No | |
| recentEvents | Yes | |
| activeRequest | No | |
| adapterRunning | Yes | |
| recentAdapterStderr | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds valuable context: it specifies what is inspected (lifecycle state, stop, DAP events, bounded stderr) and explicitly confirms no target execution change. The word 'bounded' also hints at output limits. This goes well beyond the structured annotations without contradicting them.
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 cover the full scope and intended usage with no filler. The first sentence front-loads the inspection target and side-effect-free nature, and the second provides concrete use cases and exclusions. Every clause 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?
With no parameters, rich annotations, an existing output schema, and a description that explains both the contents inspected and the intended decision-making context, nothing essential is missing. The agent can safely call this tool based on the description alone.
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, so there is no parameter semantics to clarify. The baseline of 4 applies because no parameter documentation is needed at all, and the description correctly omits any irrelevant parameter talk.
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 ('Inspect') with an explicit resource list: debugger lifecycle state, selected stop, recent DAP events, and bounded adapter stderr. It also contrasts the tool with action-oriented siblings by stating it does not resume, launch, attach, or terminate, making its role within the sibling set clear.
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 explicit guidance on when to use the tool: to determine session state before choosing another debug tool. It also states what it is not for ('does not resume, launch, attach, or terminate'), but it does not name specific alternative tools, relying on 'another debug tool' as a generic reference. This is clear context with no named alternatives, so it fits a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preferred high-level native crash workflow. Use mode=current for an already stopped session, dump for read-only postmortem analysis, codelldb to discover CodeLLDB, lldb-dap to discover upstream LLVM lldb-dap, gdb to discover GNU GDB built-in DAP interpreter, or live with an already initialized generic DAP adapter. Do not use codelldb/lldb-dap/gdb/live when executing or attaching to the target is not authorized: those modes can run application code and cause its normal side effects, while current/dump only inspect stopped evidence. workflow.stage selects initial diagnosis, verification against a prior baseline, or the bounded autonomous cycle. Returns runtime evidence, diagnosis, verification/autonomous metadata, and debugger status with deterministic fixed/blocked/budget-exhausted outcomes where applicable.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Working directory for the selected debugger/target launch and a project-root hint for diagnosis. | |
| env | No | Environment variables supplied to the launched program in codelldb/lldb-dap/gdb modes. | |
| args | No | Command-line arguments passed to the launched program in codelldb/lldb-dap/gdb modes. | |
| mode | No | current inspects an existing stop; live uses an initialized generic DAP session; codelldb starts CodeLLDB; lldb-dap starts upstream LLVM lldb-dap; gdb starts GNU GDB with --interpreter=dap; dump opens a frozen core/minidump. | current |
| program | No | Required for codelldb/lldb-dap/gdb launch modes; optional for CodeLLDB/GDB dumps but required when dumpAdapter=lldb-dap. Local path to the native executable. | |
| request | No | For mode=live, choose whether the initialized DAP adapter launches a target or attaches to an existing authorized target. | launch |
| analysis | No | Hints used to distinguish project code from runtime, system, or third-party frames. | |
| dumpPath | No | Required for mode=dump: local path to the native core/minidump file. | |
| snapshot | No | Bounds and optional evidence categories for a runtime crash snapshot. | |
| workflow | No | Controls one-shot diagnosis, explicit verification, or the bounded autonomous crash workflow. | |
| sessionId | No | Optional DAP session ID. Omit to use the backward-compatible default session. | |
| sourceMap | No | For mode=dump, map source paths stored in debug symbols to local source paths. | |
| timeoutMs | No | Maximum milliseconds to wait for the reproduction to stop, exit, or terminate. | |
| adapterPath | No | Optional explicit debugger executable/adapter path for codelldb/lldb-dap/gdb/dump modes; omit to auto-discover the selected adapter. | |
| breakpoints | No | Optional source breakpoints configured before a live/codelldb reproduction completes setup. | |
| dumpAdapter | No | For mode=dump, choose CodeLLDB, upstream LLVM lldb-dap coreFile loading, or GNU GDB coreFile attach semantics. | codelldb |
| stopOnEntry | No | When true in codelldb/lldb-dap/gdb modes, request an initial debugger stop at program entry before normal execution. | |
| configuration | No | Required for mode=live: adapter-specific DAP launch/attach configuration. | |
| requestTimeoutMs | No | Per-request DAP timeout in milliseconds for the selected debugger adapter. |
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| status | Yes | |
| workflow | No | |
| diagnosis | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint=true annotation, the description discloses mode-specific side effects: codelldb/lldb-dap/gdb/live 'can run application code and cause its normal side effects, while current/dump only inspect stopped evidence.' It also states the deterministic outcomes (fixed/blocked/budget-exhausted), which is valuable behavioral context an agent cannot infer from the schema alone.
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 about five dense sentences, each carrying a distinct job: purpose, mode routing, safety exclusion, workflow stage selection, and return content. It is front-loaded with the core purpose and avoids restating schema details, making it very efficient for a tool with 19 parameters and nested objects.
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 highly complex tool, the description covers the key decisions an agent must make: which mode to select, when execution is unsafe, which workflow stage to use, and what the tool returns. The remaining parameter details and return shape are handled by the rich input and output schemas, so nothing essential is missing.
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 the parameter descriptions in the schema are already rich, so the baseline is 3. The tool description adds high-level grouping around mode safety and workflow stages but does not add meaningful per-parameter semantics beyond what the schema already provides.
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 identifies the tool as a 'preferred high-level native crash workflow' and enumerates the concrete modes (current, dump, codelldb, lldb-dap, gdb, live), so an agent knows what operation it performs. It does not explicitly differentiate itself from sibling tools like debug_open_dump or debug_diagnose_stop by name, which keeps it from a 5.
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 explicit routing guidance for every mode, including an explicit exclusion: 'Do not use codelldb/lldb-dap/gdb/live when executing or attaching to the target is not authorized.' It also explains why those modes are risky and why current/dump are safer, and maps workflow.stage to diagnose, verify, and autonomous behaviors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
High-level native hang workflow for all-thread triage. Use it when a live process appears stuck, deadlocked, waiting forever, or spinning and you need bounded stacks from every thread, wait-state/deadlock heuristics, and cross-thread Pointer-Provenance v2. In current mode it inspects an existing configured session and pauses a running live target when necessary; codelldb, lldb-dap, gdb, and live modes can launch or attach to an authorized local target, observe it for a bounded interval, then pause it for evidence. Do not use executable/attach modes when target execution or debugger control is not authorized, and do not treat a deadlock-candidate as a proven lock cycle because generic DAP does not expose portable lock ownership.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Working directory for adapter-owned launches and a project-root hint for hang triage. | |
| env | No | Environment variables supplied to adapter-owned launched programs. | |
| pid | No | Required for codelldb/lldb-dap/gdb attach modes; ignored for launch and generic live configuration. | |
| args | No | Command-line arguments for codelldb/lldb-dap/gdb launch modes. | |
| mode | No | current triages the configured session; live uses an already initialized generic DAP adapter; codelldb/lldb-dap/gdb discover and start that adapter before launch/attach. | current |
| program | No | Required for codelldb/lldb-dap/gdb launch; optional executable image hint for adapter-specific attach. | |
| request | No | For live or adapter-owned modes, launch starts a program and attach connects to an existing authorized process. | launch |
| analysis | No | Optional project roots/modules used to recognize project-controlled frames across all threads. | |
| observeMs | No | Bounded interval after launch/attach during which a normal stop or process exit prevents automatic hang-timeout classification. | |
| sessionId | No | Optional DAP session ID. Omit to use the backward-compatible default session. | |
| maxThreads | No | Maximum threads to collect for bounded all-thread triage. | |
| adapterPath | No | Optional explicit CodeLLDB, lldb-dap, or GDB executable path; omit to use adapter discovery. | |
| stackLevels | No | Maximum stack frames collected per thread. | |
| configuration | No | Required only for mode=live: adapter-specific DAP launch/attach configuration. | |
| pauseBudgetMs | No | Aggregate wall-clock budget across thread enumeration and all pause requests. This prevents per-thread pause timeouts from multiplying across large thread sets. | |
| pauseTimeoutMs | No | Maximum time to wait for any single pause request used to freeze a suspected live hang. | |
| captureTimeoutMs | No | Global deadline for all-thread stack/scope/variable evidence collection after the pause phase. When it expires, remaining threads are retained as partial/unclassified evidence instead of extending the workflow per thread. | |
| requestTimeoutMs | No | Per-request timeout for starting and configuring an adapter-owned DAP session. | |
| framesWithVariables | No | Maximum frames per thread whose locals/arguments are collected, prioritizing the top frame and first project-controlled frame. | |
| maxVariablesPerFrame | No | Maximum local/argument variables collected per selected frame scope for Pointer-Provenance v2. |
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| status | Yes | |
| evidence | No | |
| diagnosis | No | |
| observation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry destructiveHint=true, so the destructive nature is known. The description adds meaningful behavioral context beyond that: it can pause a running live target, launches or attaches via several adapters, observes for a bounded interval, and explicitly warns that generic DAP cannot prove lock ownership. This is valuable operational disclosure that annotations do not provide.
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 dense but every sentence earns its place: the first sentence states purpose and trigger conditions, the second explains mode behavior, the third states a safety exclusion, and the fourth adds an important epistemic caveat about lock-cycle interpretation. Content is front-loaded and there is no filler.
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 tool this complex—20 parameters, nested objects, five modes, output schema present, and rich annotations—the description covers the essential workflow, mode distinctions, and safety boundaries. It could be more complete by explicitly contrasting with debug_this_crash, but an agent has enough to call it correctly given the exhaustive input schema and output schema.
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%, with each parameter already documented in detail. The description adds workflow-level context but no per-parameter meaning beyond the schema, so the baseline 3 is appropriate: the structured field descriptions do the heavy lifting.
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 a specific verb and resource: a 'high-level native hang workflow for all-thread triage.' It immediately names the triggering conditions (stuck, deadlocked, waiting forever, spinning) and the deliverable (bounded stacks from every thread, wait-state/deadlock heuristics, Pointer-Provenance v2), which clearly distinguishes it from the sibling crash-focused tools like debug_this_crash.
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 explicit when-to-use criteria ('Use it when a live process appears stuck...') and a clear exclusion: do not use executable/attach modes when target execution or debugger control is not authorized. It does not explicitly name which sibling to use instead for crash triage, so it falls just short of full alternative routing, but the context is otherwise strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a bounded temporal write timeline for one debugger-visible variable or expression. Use this after differential or crash evidence identifies a suspicious value and repeated live-target resume is safe. The tool installs one temporary data breakpoint or watchpoint at a time, resumes to the next confirmed writer, captures bounded runtime evidence, removes only its own temporary watch, and repeats. Do not use it for crash dumps, unsafe-to-resume targets, or as proof that an observed writer is the root cause; it stops on unrelated debugger events rather than continuing through them.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Debugger-visible variable or expression to watch. Control characters and line breaks are rejected by the GDB fallback. | |
| maxStops | No | Maximum confirmed or unrelated writer-stop observations before the trace ends. | |
| snapshot | No | Optional bounded evidence settings for each observed writer stop. | |
| threadId | No | Initial stopped thread; omit to use the debugger-selected stopped thread. Writer snapshots follow the actual stopped event thread. | |
| sessionId | No | Optional DAP session ID. Omit to use the backward-compatible default session. | |
| timeoutMs | No | Aggregate operation deadline across the entire write timeline. | |
| accessType | No | Watch writes only by default; readWrite may be used when read access is also relevant. | write |
| perStopTimeoutMs | No | Maximum bounded wait allocated to each individual writer observation, also capped by the aggregate deadline. |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| events | Yes | |
| status | Yes | |
| guidance | Yes | |
| stopReason | Yes | |
| finalSnapshot | Yes | |
| terminalError | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses substantial behavioral detail beyond the annotations: it installs one temporary breakpoint/watchpoint at a time, resumes to the next confirmed writer, captures bounded evidence, removes only its own watch, and repeats. It also reveals a key limitation: the tool stops on unrelated debugger events rather than continuing through them. The destructiveHint and openWorldHint annotations are consistent with this live-target mutating 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 dense but efficient, front-loading the core purpose, then usage context, then operational behavior, then exclusions. Every sentence earns its place, and no content is repeated from the schema or annotations.
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, the description covers the essential operational model, safety preconditions, limitations, and unsupported uses. An output schema exists, so the description does not need to explain return values. The combination of schema, annotations, and description gives an agent enough context to decide when and how to invoke the tool correctly.
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 already has a meaningful description, including defaults, bounds, and semantics such as aggregation deadline and per-stop timeout. The tool description reinforces general concepts like 'bounded' and 'writer stops' but does not add significant parameter-level meaning beyond what the schema already provides.
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 opens with a specific verb and resource: 'Build a bounded temporal write timeline for one debugger-visible variable or expression.' This directly states what the tool does and differentiates it from broader debugging or dump-analysis tools by focusing on a single variable/expression and a timeline of writes.
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 explicit when-to-use guidance: after differential or crash evidence identifies a suspicious value and live-target resume is safe. It also gives clear when-not-to-use conditions: crash dumps, unsafe-to-resume targets, and as root-cause proof. However, it does not name alternative sibling tools to use in those excluded cases, so it falls one step short of the strongest guidance.
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.
v0.17.0debug_compare_runsdebug_continue2 fields changedInput schema / properties / sessionIdAdded value: +{
+ "description": "Optional DAP session ID. Omit to use the backward-compatible default session.",
+ "maxLength": 64,
+ "minLength": 1,
+ "pattern": "^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$",
+ "type": "string"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "allThreadsContinued": {
+ "type": "boolean"
+ },
+ "response": {},
+ "stopped": {}
+ },
+ "type": "object"
+}debug_diagnose_stop2 fields changedInput schema / properties / sessionIdAdded value: +{
+ "description": "Optional DAP session ID. Omit to use the backward-compatible default session.",
+ "maxLength": 64,
+ "minLength": 1,
+ "pattern": "^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$",
+ "type": "string"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "diagnosis": {},
+ "snapshot": {
+ "additionalProperties": {},
+ "properties": {
+ "collectionErrors": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "message": {
+ "type": "string"
+ },
+ "operation": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "operation",
+ "message"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "disassembly": {
+ "items": {},
+ "type": "array"
+ },
+ "exception": {},
+ "frame": {
+ "additionalProperties": {},
+ "properties": {
+ "column": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "id": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "line": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "name": {
+ "type": "string"
+ },
+ "source": {}
+ },
+ "required": [
+ "id",
+ "name",
+ "line",
+ "column"
+ ],
+ "type": "object"
+ },
+ "locals": {
+ "items": {},
+ "type": "array"
+ },
+ "modules": {
+ "items": {},
+ "type": "array"
+ },
+ "postmortem": {
+ "type": "boolean"
+ },
+ "registers": {
+ "items": {},
+ "type": "array"
+ },
+ "scopes": {
+ "items": {},
+ "type": "array"
+ },
+ "stack": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "column": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "id": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "line": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "name": {
+ "type": "string"
+ },
+ "source": {}
+ },
+ "required": [
+ "id",
+ "name",
+ "line",
+ "column"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "stopped": {},
+ "symbolHealth": {
+ "additionalProperties": false,
+ "properties": {
+ "limitations": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "modules": {
+ "additionalProperties": false,
+ "properties": {
+ "collected": {
+ "type": "boolean"
+ },
+ "symbolsAvailable": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "symbolsMissing": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "symbolsUnknown": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "totalModules": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "withExplicitStatus": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "collected",
+ "totalModules",
+ "withExplicitStatus",
+ "symbolsAvailable",
+ "symbolsMissing",
+ "symbolsUnknown"
+ ],
+ "type": "object"
+ },
+ "stack": {
+ "additionalProperties": false,
+ "properties": {
+ "namedFrames": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "sourceMappedFrames": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "topFrameNamed": {
+ "type": "boolean"
+ },
+ "topFrameSourceMapped": {
+ "type": "boolean"
+ },
+ "totalFrames": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "totalFrames",
+ "namedFrames",
+ "sourceMappedFrames",
+ "topFrameNamed",
+ "topFrameSourceMapped"
+ ],
+ "type": "object"
+ },
+ "status": {
+ "enum": [
+ "good",
+ "partial",
+ "poor",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "summary",
+ "stack",
+ "modules",
+ "limitations"
+ ],
+ "type": "object"
+ },
+ "thread": {
+ "additionalProperties": {},
+ "properties": {
+ "id": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "thread",
+ "stack",
+ "frame",
+ "scopes",
+ "locals",
+ "registers",
+ "symbolHealth"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "snapshot",
+ "diagnosis"
+ ],
+ "type": "object"
+}debug_disconnect2 fields changedInput schema / properties / sessionIdAdded value: +{
+ "description": "Optional DAP session ID. Omit to use the backward-compatible default session.",
+ "maxLength": 64,
+ "minLength": 1,
+ "pattern": "^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$",
+ "type": "string"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "disconnected": {
+ "const": true,
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "disconnected"
+ ],
+ "type": "object"
+}debug_find_writerdebug_open_dump6 fields changedInput schema / properties / adapter / descriptionPrevious value: -"Debugger adapter used for postmortem inspection. codelldb preserves existing behavior; lldb-dap uses upstream LLVM coreFile attach semantics."New value: +"Debugger adapter used for postmortem inspection. lldb-dap and gdb use their native coreFile attach semantics."Input schema / properties / adapter / enumPrevious value: -[
- "codelldb",
- "lldb-dap"
-]New value: +[
+ "codelldb",
+ "lldb-dap",
+ "gdb"
+]Input schema / properties / program / descriptionPrevious value: -"Path to the matching executable image. Optional for CodeLLDB, but required when adapter=lldb-dap because LLVM coreFile loading binds the dump to its program image."New value: +"Path to the matching executable image. Optional for CodeLLDB/GDB, but required when adapter=lldb-dap because LLVM coreFile loading binds the dump to its program image."Input schema / properties / sessionIdAdded value: +{
+ "description": "Optional DAP session ID. Omit to use the backward-compatible default session.",
+ "maxLength": 64,
+ "minLength": 1,
+ "pattern": "^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$",
+ "type": "string"
+}Input schema / properties / sourceMap / descriptionPrevious value: -"Optional mapping from source paths recorded in symbols to local source paths; converted to lldb-dap pair arrays when that adapter is selected."New value: +"Optional mapping from source paths recorded in symbols to local source paths. Supported by CodeLLDB/lldb-dap; GDB currently rejects this field rather than guessing undocumented semantics."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "adapter": {},
+ "adapterKind": {
+ "enum": [
+ "codelldb",
+ "lldb-dap",
+ "gdb"
+ ],
+ "type": "string"
+ },
+ "attach": {},
+ "capabilities": {},
+ "dumpPath": {
+ "type": "string"
+ },
+ "guidance": {
+ "additionalProperties": {},
+ "properties": {
+ "blockedOperations": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "canInspect": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "cannotResume": {
+ "type": "boolean"
+ },
+ "note": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "canInspect",
+ "blockedOperations",
+ "cannotResume",
+ "note"
+ ],
+ "type": "object"
+ },
+ "mode": {
+ "const": "postmortem",
+ "type": "string"
+ },
+ "program": {
+ "type": "string"
+ },
+ "readOnlyTarget": {
+ "const": true,
+ "type": "boolean"
+ },
+ "snapshot": {
+ "additionalProperties": {},
+ "properties": {
+ "collectionErrors": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "message": {
+ "type": "string"
+ },
+ "operation": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "operation",
+ "message"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "disassembly": {
+ "items": {},
+ "type": "array"
+ },
+ "exception": {},
+ "frame": {
+ "additionalProperties": {},
+ "properties": {
+ "column": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "id": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "line": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "name": {
+ "type": "string"
+ },
+ "source": {}
+ },
+ "required": [
+ "id",
+ "name",
+ "line",
+ "column"
+ ],
+ "type": "object"
+ },
+ "locals": {
+ "items": {},
+ "type": "array"
+ },
+ "modules": {
+ "items": {},
+ "type": "array"
+ },
+ "postmortem": {
+ "type": "boolean"
+ },
+ "registers": {
+ "items": {},
+ "type": "array"
+ },
+ "scopes": {
+ "items": {},
+ "type": "array"
+ },
+ "stack": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "column": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "id": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "line": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "name": {
+ "type": "string"
+ },
+ "source": {}
+ },
+ "required": [
+ "id",
+ "name",
+ "line",
+ "column"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "stopped": {},
+ "symbolHealth": {
+ "additionalProperties": false,
+ "properties": {
+ "limitations": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "modules": {
+ "additionalProperties": false,
+ "properties": {
+ "collected": {
+ "type": "boolean"
+ },
+ "symbolsAvailable": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "symbolsMissing": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "symbolsUnknown": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "totalModules": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "withExplicitStatus": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "collected",
+ "totalModules",
+ "withExplicitStatus",
+ "symbolsAvailable",
+ "symbolsMissing",
+ "symbolsUnknown"
+ ],
+ "type": "object"
+ },
+ "stack": {
+ "additionalProperties": false,
+ "properties": {
+ "namedFrames": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "sourceMappedFrames": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "topFrameNamed": {
+ "type": "boolean"
+ },
+ "topFrameSourceMapped": {
+ "type": "boolean"
+ },
+ "totalFrames": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "totalFrames",
+ "namedFrames",
+ "sourceMappedFrames",
+ "topFrameNamed",
+ "topFrameSourceMapped"
+ ],
+ "type": "object"
+ },
+ "status": {
+ "enum": [
+ "good",
+ "partial",
+ "poor",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "summary",
+ "stack",
+ "modules",
+ "limitations"
+ ],
+ "type": "object"
+ },
+ "thread": {
+ "additionalProperties": {},
+ "properties": {
+ "id": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "thread",
+ "stack",
+ "frame",
+ "scopes",
+ "locals",
+ "registers",
+ "symbolHealth"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "mode",
+ "readOnlyTarget",
+ "adapterKind",
+ "dumpPath",
+ "adapter",
+ "capabilities",
+ "attach",
+ "snapshot",
+ "guidance"
+ ],
+ "type": "object"
+}debug_run_to_stop2 fields changedInput schema / properties / sessionIdAdded value: +{
+ "description": "Optional DAP session ID. Omit to use the backward-compatible default session.",
+ "maxLength": 64,
+ "minLength": 1,
+ "pattern": "^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$",
+ "type": "string"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "outcome": {
+ "additionalProperties": false,
+ "properties": {
+ "body": {},
+ "event": {
+ "enum": [
+ "stopped",
+ "exited",
+ "terminated"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "event"
+ ],
+ "type": "object"
+ },
+ "request": {
+ "enum": [
+ "launch",
+ "attach"
+ ],
+ "type": "string"
+ },
+ "requestResult": {},
+ "snapshot": {
+ "additionalProperties": {},
+ "properties": {
+ "collectionErrors": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "message": {
+ "type": "string"
+ },
+ "operation": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "operation",
+ "message"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "disassembly": {
+ "items": {},
+ "type": "array"
+ },
+ "exception": {},
+ "frame": {
+ "additionalProperties": {},
+ "properties": {
+ "column": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "id": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "line": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "name": {
+ "type": "string"
+ },
+ "source": {}
+ },
+ "required": [
+ "id",
+ "name",
+ "line",
+ "column"
+ ],
+ "type": "object"
+ },
+ "locals": {
+ "items": {},
+ "type": "array"
+ },
+ "modules": {
+ "items": {},
+ "type": "array"
+ },
+ "postmortem": {
+ "type": "boolean"
+ },
+ "registers": {
+ "items": {},
+ "type": "array"
+ },
+ "scopes": {
+ "items": {},
+ "type": "array"
+ },
+ "stack": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "column": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "id": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "line": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "name": {
+ "type": "string"
+ },
+ "source": {}
+ },
+ "required": [
+ "id",
+ "name",
+ "line",
+ "column"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "stopped": {},
+ "symbolHealth": {
+ "additionalProperties": false,
+ "properties": {
+ "limitations": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "modules": {
+ "additionalProperties": false,
+ "properties": {
+ "collected": {
+ "type": "boolean"
+ },
+ "symbolsAvailable": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "symbolsMissing": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "symbolsUnknown": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "totalModules": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "withExplicitStatus": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "collected",
+ "totalModules",
+ "withExplicitStatus",
+ "symbolsAvailable",
+ "symbolsMissing",
+ "symbolsUnknown"
+ ],
+ "type": "object"
+ },
+ "stack": {
+ "additionalProperties": false,
+ "properties": {
+ "namedFrames": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "sourceMappedFrames": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "topFrameNamed": {
+ "type": "boolean"
+ },
+ "topFrameSourceMapped": {
+ "type": "boolean"
+ },
+ "totalFrames": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "totalFrames",
+ "namedFrames",
+ "sourceMappedFrames",
+ "topFrameNamed",
+ "topFrameSourceMapped"
+ ],
+ "type": "object"
+ },
+ "status": {
+ "enum": [
+ "good",
+ "partial",
+ "poor",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "summary",
+ "stack",
+ "modules",
+ "limitations"
+ ],
+ "type": "object"
+ },
+ "thread": {
+ "additionalProperties": {},
+ "properties": {
+ "id": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "thread",
+ "stack",
+ "frame",
+ "scopes",
+ "locals",
+ "registers",
+ "symbolHealth"
+ ],
+ "type": "object"
+ },
+ "status": {}
+ },
+ "required": [
+ "request",
+ "requestResult",
+ "outcome",
+ "status"
+ ],
+ "type": "object"
+}debug_sessionsdebug_snapshot2 fields changedInput schema / properties / sessionIdAdded value: +{
+ "description": "Optional DAP session ID. Omit to use the backward-compatible default session.",
+ "maxLength": 64,
+ "minLength": 1,
+ "pattern": "^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$",
+ "type": "string"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "collectionErrors": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "message": {
+ "type": "string"
+ },
+ "operation": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "operation",
+ "message"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "disassembly": {
+ "items": {},
+ "type": "array"
+ },
+ "exception": {},
+ "frame": {
+ "additionalProperties": {},
+ "properties": {
+ "column": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "id": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "line": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "name": {
+ "type": "string"
+ },
+ "source": {}
+ },
+ "required": [
+ "id",
+ "name",
+ "line",
+ "column"
+ ],
+ "type": "object"
+ },
+ "locals": {
+ "items": {},
+ "type": "array"
+ },
+ "modules": {
+ "items": {},
+ "type": "array"
+ },
+ "postmortem": {
+ "type": "boolean"
+ },
+ "registers": {
+ "items": {},
+ "type": "array"
+ },
+ "scopes": {
+ "items": {},
+ "type": "array"
+ },
+ "stack": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "column": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "id": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "line": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "name": {
+ "type": "string"
+ },
+ "source": {}
+ },
+ "required": [
+ "id",
+ "name",
+ "line",
+ "column"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "stopped": {},
+ "symbolHealth": {
+ "additionalProperties": false,
+ "properties": {
+ "limitations": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "modules": {
+ "additionalProperties": false,
+ "properties": {
+ "collected": {
+ "type": "boolean"
+ },
+ "symbolsAvailable": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "symbolsMissing": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "symbolsUnknown": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "totalModules": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "withExplicitStatus": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "collected",
+ "totalModules",
+ "withExplicitStatus",
+ "symbolsAvailable",
+ "symbolsMissing",
+ "symbolsUnknown"
+ ],
+ "type": "object"
+ },
+ "stack": {
+ "additionalProperties": false,
+ "properties": {
+ "namedFrames": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "sourceMappedFrames": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "topFrameNamed": {
+ "type": "boolean"
+ },
+ "topFrameSourceMapped": {
+ "type": "boolean"
+ },
+ "totalFrames": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "totalFrames",
+ "namedFrames",
+ "sourceMappedFrames",
+ "topFrameNamed",
+ "topFrameSourceMapped"
+ ],
+ "type": "object"
+ },
+ "status": {
+ "enum": [
+ "good",
+ "partial",
+ "poor",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "summary",
+ "stack",
+ "modules",
+ "limitations"
+ ],
+ "type": "object"
+ },
+ "thread": {
+ "additionalProperties": {},
+ "properties": {
+ "id": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "thread",
+ "stack",
+ "frame",
+ "scopes",
+ "locals",
+ "registers",
+ "symbolHealth"
+ ],
+ "type": "object"
+}debug_source_disassembly2 fields changedInput schema / properties / sessionIdAdded value: +{
+ "description": "Optional DAP session ID. Omit to use the backward-compatible default session.",
+ "maxLength": 64,
+ "minLength": 1,
+ "pattern": "^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$",
+ "type": "string"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "collectionErrors": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "faultCorrelation": {},
+ "frameSelection": {},
+ "operandAnalysis": {},
+ "projectCorrelation": {},
+ "projectFrame": {
+ "additionalProperties": {},
+ "properties": {
+ "column": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "id": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "line": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "name": {
+ "type": "string"
+ },
+ "source": {}
+ },
+ "required": [
+ "id",
+ "name",
+ "line",
+ "column"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "frameSelection",
+ "faultCorrelation",
+ "projectCorrelation",
+ "projectFrame",
+ "operandAnalysis"
+ ],
+ "type": "object"
+}debug_status1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "activeRequest": {
+ "enum": [
+ "launch",
+ "attach"
+ ],
+ "type": "string"
+ },
+ "adapterId": {
+ "type": "string"
+ },
+ "adapterPid": {
+ "exclusiveMinimum": 0,
+ "maximum": 9007199254740991,
+ "type": "integer"
+ },
+ "adapterRunning": {
+ "type": "boolean"
+ },
+ "capabilities": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "configured": {
+ "type": "boolean"
+ },
+ "initialized": {
+ "type": "boolean"
+ },
+ "recentAdapterStderr": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "recentEvents": {
+ "items": {},
+ "type": "array"
+ }
+ },
+ "required": [
+ "adapterRunning",
+ "initialized",
+ "configured",
+ "recentEvents",
+ "recentAdapterStderr"
+ ],
+ "type": "object"
+}debug_this_crash12 fields changedInput schema / properties / adapterPath / descriptionPrevious value: -"Optional explicit debugger-adapter executable path for codelldb/lldb-dap/dump modes; omit to auto-discover the selected adapter."New value: +"Optional explicit debugger executable/adapter path for codelldb/lldb-dap/gdb/dump modes; omit to auto-discover the selected adapter."Input schema / properties / args / descriptionPrevious value: -"Command-line arguments passed to the launched program in mode=codelldb or mode=lldb-dap."New value: +"Command-line arguments passed to the launched program in codelldb/lldb-dap/gdb modes."Input schema / properties / dumpAdapter / descriptionPrevious value: -"For mode=dump, choose CodeLLDB compatibility behavior or upstream LLVM lldb-dap coreFile loading."New value: +"For mode=dump, choose CodeLLDB, upstream LLVM lldb-dap coreFile loading, or GNU GDB coreFile attach semantics."Input schema / properties / dumpAdapter / enumPrevious value: -[
- "codelldb",
- "lldb-dap"
-]New value: +[
+ "codelldb",
+ "lldb-dap",
+ "gdb"
+]Input schema / properties / env / descriptionPrevious value: -"Environment variables supplied to the launched program in mode=codelldb or mode=lldb-dap."New value: +"Environment variables supplied to the launched program in codelldb/lldb-dap/gdb modes."Input schema / properties / mode / descriptionPrevious value: -"current inspects an existing stop; live runs launch/attach through an initialized DAP session; codelldb starts CodeLLDB; lldb-dap starts upstream LLVM lldb-dap; dump opens a frozen core/minidump."New value: +"current inspects an existing stop; live uses an initialized generic DAP session; codelldb starts CodeLLDB; lldb-dap starts upstream LLVM lldb-dap; gdb starts GNU GDB with --interpreter=dap; dump opens a frozen core/minidump."Input schema / properties / mode / enumPrevious value: -[
- "current",
- "live",
- "codelldb",
- "lldb-dap",
- "dump"
-]New value: +[
+ "current",
+ "live",
+ "codelldb",
+ "lldb-dap",
+ "gdb",
+ "dump"
+]Input schema / properties / program / descriptionPrevious value: -"Required for mode=codelldb and mode=lldb-dap; optional for CodeLLDB dumps but required when dumpAdapter=lldb-dap. Local path to the native executable."New value: +"Required for codelldb/lldb-dap/gdb launch modes; optional for CodeLLDB/GDB dumps but required when dumpAdapter=lldb-dap. Local path to the native executable."Input schema / properties / requestTimeoutMs / descriptionPrevious value: -"Per-request DAP timeout in milliseconds for CodeLLDB operations."New value: +"Per-request DAP timeout in milliseconds for the selected debugger adapter."Input schema / properties / sessionIdAdded value: +{
+ "description": "Optional DAP session ID. Omit to use the backward-compatible default session.",
+ "maxLength": 64,
+ "minLength": 1,
+ "pattern": "^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$",
+ "type": "string"
+}Input schema / properties / stopOnEntry / descriptionPrevious value: -"When true in mode=codelldb or mode=lldb-dap, request an initial debugger stop at program entry before normal execution."New value: +"When true in codelldb/lldb-dap/gdb modes, request an initial debugger stop at program entry before normal execution."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "diagnosis": {},
+ "mode": {
+ "enum": [
+ "current",
+ "live",
+ "codelldb",
+ "lldb-dap",
+ "gdb",
+ "dump"
+ ],
+ "type": "string"
+ },
+ "status": {
+ "additionalProperties": {},
+ "properties": {
+ "activeRequest": {
+ "enum": [
+ "launch",
+ "attach"
+ ],
+ "type": "string"
+ },
+ "adapterId": {
+ "type": "string"
+ },
+ "adapterPid": {
+ "exclusiveMinimum": 0,
+ "maximum": 9007199254740991,
+ "type": "integer"
+ },
+ "adapterRunning": {
+ "type": "boolean"
+ },
+ "capabilities": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "configured": {
+ "type": "boolean"
+ },
+ "initialized": {
+ "type": "boolean"
+ },
+ "recentAdapterStderr": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "recentEvents": {
+ "items": {},
+ "type": "array"
+ }
+ },
+ "required": [
+ "adapterRunning",
+ "initialized",
+ "configured",
+ "recentEvents",
+ "recentAdapterStderr"
+ ],
+ "type": "object"
+ },
+ "workflow": {}
+ },
+ "required": [
+ "mode",
+ "status"
+ ],
+ "type": "object"
+}debug_this_hangdebug_trace_valuev0.13.0debug_open_dump5 fields changedInput schema / properties / adapterAdded value: +{
+ "default": "codelldb",
+ "description": "Debugger adapter used for postmortem inspection. codelldb preserves existing behavior; lldb-dap uses upstream LLVM coreFile attach semantics.",
+ "enum": [
+ "codelldb",
+ "lldb-dap"
+ ],
+ "type": "string"
+}Input schema / properties / adapterPath / descriptionPrevious value: -"Optional explicit CodeLLDB executable path; omit to use normal CodeLLDB discovery."New value: +"Optional explicit executable path for the selected debugger adapter; omit to use its normal discovery logic."Input schema / properties / cwd / descriptionPrevious value: -"Working directory for the local CodeLLDB adapter process; this does not execute the crashed target."New value: +"Working directory for the local debugger adapter process; this does not execute the crashed target."Input schema / properties / program / descriptionPrevious value: -"Optional path to the matching executable image, used by CodeLLDB to improve symbol/module resolution."New value: +"Path to the matching executable image. Optional for CodeLLDB, but required when adapter=lldb-dap because LLVM coreFile loading binds the dump to its program image."Input schema / properties / sourceMap / descriptionPrevious value: -"Optional mapping from source paths recorded in symbols to local source paths."New value: +"Optional mapping from source paths recorded in symbols to local source paths; converted to lldb-dap pair arrays when that adapter is selected."debug_this_crash9 fields changedInput schema / properties / adapterPath / descriptionPrevious value: -"Optional explicit CodeLLDB executable path for codelldb/dump modes; omit to auto-discover it."New value: +"Optional explicit debugger-adapter executable path for codelldb/lldb-dap/dump modes; omit to auto-discover the selected adapter."Input schema / properties / args / descriptionPrevious value: -"Command-line arguments passed to the launched program in mode=codelldb."New value: +"Command-line arguments passed to the launched program in mode=codelldb or mode=lldb-dap."Input schema / properties / cwd / descriptionPrevious value: -"Working directory for CodeLLDB/target launch and a project-root hint for diagnosis."New value: +"Working directory for the selected debugger/target launch and a project-root hint for diagnosis."Input schema / properties / dumpAdapterAdded value: +{
+ "default": "codelldb",
+ "description": "For mode=dump, choose CodeLLDB compatibility behavior or upstream LLVM lldb-dap coreFile loading.",
+ "enum": [
+ "codelldb",
+ "lldb-dap"
+ ],
+ "type": "string"
+}Input schema / properties / env / descriptionPrevious value: -"Environment variables supplied to the launched program in mode=codelldb."New value: +"Environment variables supplied to the launched program in mode=codelldb or mode=lldb-dap."Input schema / properties / mode / descriptionPrevious value: -"current inspects an existing stop; live runs launch/attach through an initialized DAP session; codelldb starts CodeLLDB and launches program; dump opens a frozen core/minidump."New value: +"current inspects an existing stop; live runs launch/attach through an initialized DAP session; codelldb starts CodeLLDB; lldb-dap starts upstream LLVM lldb-dap; dump opens a frozen core/minidump."Input schema / properties / mode / enumPrevious value: -[
- "current",
- "live",
- "codelldb",
- "dump"
-]New value: +[
+ "current",
+ "live",
+ "codelldb",
+ "lldb-dap",
+ "dump"
+]Input schema / properties / program / descriptionPrevious value: -"Required for mode=codelldb; optional for dump symbol resolution. Local path to the native executable."New value: +"Required for mode=codelldb and mode=lldb-dap; optional for CodeLLDB dumps but required when dumpAdapter=lldb-dap. Local path to the native executable."Input schema / properties / stopOnEntry / descriptionPrevious value: -"When true in mode=codelldb, request an initial debugger stop at program entry before normal execution."New value: +"When true in mode=codelldb or mode=lldb-dap, request an initial debugger stop at program entry before normal execution."v0.12.1debug_continue3 fields changedInput schema / properties / threadId / descriptionAdded value: +"DAP thread identifier to resume; obtain it from debug_snapshot, debug_status, or a stopped event."Input schema / properties / timeoutMs / descriptionAdded value: +"Maximum time in milliseconds to wait for the next stopped event when waitForStop is true."Input schema / properties / waitForStop / descriptionAdded value: +"When true, wait for the next stopped event before returning; when false, return after the continue request is accepted."debug_diagnose_stop13 fields changedInput schema / properties / analysis / descriptionAdded value: +"Hints used to distinguish project code from runtime, system, or third-party frames."Input schema / properties / analysis / properties / callerDepth / descriptionAdded value: +"How many project-controlled caller frames beyond the selected frame to inspect for provenance and root cause."Input schema / properties / analysis / properties / projectModules / descriptionAdded value: +"Optional executable or library names treated as project-controlled modules during frame selection."Input schema / properties / analysis / properties / projectRoots / descriptionAdded value: +"Optional local source-root paths used to recognize project-controlled stack frames."Input schema / properties / disassembleAfter / descriptionAdded value: +"Number of instructions after the selected instruction to request."Input schema / properties / disassembleBefore / descriptionAdded value: +"Number of instructions before the selected instruction to request."Input schema / properties / includeDisassembly / descriptionAdded value: +"Include best-effort disassembly around the selected instruction pointer when supported."Input schema / properties / includeExceptionInfo / descriptionAdded value: +"Request structured exception information for the stopped thread when supported."Input schema / properties / includeModules / descriptionAdded value: +"Include a bounded list of loaded executable images and libraries."Input schema / properties / maxVariablesPerScope / descriptionAdded value: +"Maximum variables returned per inspected scope, bounding evidence size."Input schema / properties / moduleCount / descriptionAdded value: +"Maximum loaded modules to include when module collection is enabled."Input schema / properties / stackLevels / descriptionAdded value: +"Maximum number of stack frames to inspect when collecting crash evidence."Input schema / properties / threadId / descriptionAdded value: +"Stopped DAP thread to inspect; omit to use the session-selected stopped thread."debug_disconnect1 field changedInput schema / properties / terminateDebuggee / descriptionAdded value: +"Whether the debugger should terminate the live debuggee while disconnecting; set false to request detach/preserve behavior when the adapter supports it."debug_open_dump12 fields changedInput schema / properties / adapterPath / descriptionAdded value: +"Optional explicit CodeLLDB executable path; omit to use normal CodeLLDB discovery."Input schema / properties / cwd / descriptionAdded value: +"Working directory for the local CodeLLDB adapter process; this does not execute the crashed target."Input schema / properties / dumpPath / descriptionAdded value: +"Absolute or local path to the native core/minidump file to inspect."Input schema / properties / includeDisassembly / descriptionAdded value: +"Include best-effort instructions around the selected crash frame."Input schema / properties / includeModules / descriptionAdded value: +"Include loaded executable images and libraries recorded in the dump."Input schema / properties / maxVariablesPerScope / descriptionAdded value: +"Maximum variables returned per scope in the initial snapshot."Input schema / properties / moduleCount / descriptionAdded value: +"Maximum number of modules to include when includeModules is true."Input schema / properties / program / descriptionAdded value: +"Optional path to the matching executable image, used by CodeLLDB to improve symbol/module resolution."Input schema / properties / requestTimeoutMs / descriptionAdded value: +"Per-request DAP timeout in milliseconds while opening and inspecting the dump."Input schema / properties / sourceMap / descriptionAdded value: +"Optional mapping from source paths recorded in symbols to local source paths."Input schema / properties / stackLevels / descriptionAdded value: +"Maximum stack frames to include in the initial postmortem snapshot."Input schema / properties / threadId / descriptionAdded value: +"Specific dump thread to inspect; omit to use the debugger-selected stopped/crashed thread."debug_run_to_stop17 fields changedInput schema / properties / breakpoints / descriptionAdded value: +"Optional source breakpoint groups configured before the debugger completes launch/attach setup."Input schema / properties / breakpoints / items / descriptionAdded value: +"Source file and line breakpoints applied before configuration completes."Input schema / properties / breakpoints / items / properties / lines / descriptionAdded value: +"One or more 1-based source line numbers to replace as breakpoints for this source file."Input schema / properties / breakpoints / items / properties / source / descriptionPrevious value: -"Absolute or adapter-resolvable source file path"New value: +"Absolute or adapter-resolvable source file path."Input schema / properties / configuration / descriptionAdded value: +"Adapter-specific DAP launch or attach configuration."Input schema / properties / request / descriptionAdded value: +"Choose launch to start a new target from configuration, or attach to connect to an existing authorized local target."Input schema / properties / snapshot / descriptionAdded value: +"Optional bounds and evidence categories for the snapshot captured only when execution stops."Input schema / properties / snapshot / properties / disassembleAfter / descriptionAdded value: +"Instructions after the selected instruction to request."Input schema / properties / snapshot / properties / disassembleBefore / descriptionAdded value: +"Instructions before the selected instruction to request."Input schema / properties / snapshot / properties / includeDisassembly / descriptionAdded value: +"Whether to include best-effort disassembly near the selected frame."Input schema / properties / snapshot / properties / includeExceptionInfo / descriptionAdded value: +"Whether to request structured exception information after a stop."Input schema / properties / snapshot / properties / includeModules / descriptionAdded value: +"Whether to include a bounded loaded-module list."Input schema / properties / snapshot / properties / maxVariablesPerScope / descriptionAdded value: +"Maximum variables to return per inspected scope."Input schema / properties / snapshot / properties / moduleCount / descriptionAdded value: +"Maximum loaded modules to include."Input schema / properties / snapshot / properties / stackLevels / descriptionAdded value: +"Maximum stack frames to collect after a stop."Input schema / properties / snapshot / properties / threadId / descriptionAdded value: +"Stopped thread to snapshot; omit to use the thread from the stopped event."Input schema / properties / timeoutMs / descriptionAdded value: +"Maximum milliseconds to wait for the first stopped, exited, or terminated event."debug_snapshot9 fields changedInput schema / properties / disassembleAfter / descriptionAdded value: +"Number of instructions after the current instruction to request when disassembly is enabled."Input schema / properties / disassembleBefore / descriptionAdded value: +"Number of instructions before the current instruction to request when disassembly is enabled."Input schema / properties / includeDisassembly / descriptionAdded value: +"Include best-effort instructions around the selected frame instruction pointer when supported."Input schema / properties / includeExceptionInfo / descriptionAdded value: +"Include structured exception information for the stopped thread when the adapter supports it."Input schema / properties / includeModules / descriptionAdded value: +"Include a bounded list of loaded executable images and libraries."Input schema / properties / maxVariablesPerScope / descriptionAdded value: +"Maximum variables returned per inspected scope, bounding output size."Input schema / properties / moduleCount / descriptionAdded value: +"Maximum loaded modules to return when includeModules is true."Input schema / properties / stackLevels / descriptionAdded value: +"Maximum number of stack frames to include, from the selected thread top downward."Input schema / properties / threadId / descriptionAdded value: +"Stopped DAP thread to inspect; omit to use the session-selected stopped thread."debug_source_disassembly8 fields changedInput schema / properties / analysis / descriptionAdded value: +"Hints used to distinguish project code from runtime, system, or third-party frames."Input schema / properties / analysis / properties / callerDepth / descriptionAdded value: +"How many project-controlled caller frames beyond the selected frame to inspect for provenance and root cause."Input schema / properties / analysis / properties / projectModules / descriptionAdded value: +"Optional executable or library names treated as project-controlled modules during frame selection."Input schema / properties / analysis / properties / projectRoots / descriptionAdded value: +"Optional local source-root paths used to recognize project-controlled stack frames."Input schema / properties / disassembleAfter / descriptionAdded value: +"Instructions after the selected instruction included in each disassembly window."Input schema / properties / disassembleBefore / descriptionAdded value: +"Instructions before the selected instruction included in each disassembly window."Input schema / properties / stackLevels / descriptionAdded value: +"Maximum stack frames considered while selecting the project-controlled frame."Input schema / properties / threadId / descriptionAdded value: +"Stopped DAP thread to inspect; omit to use the session-selected stopped thread."debug_this_crash36 fields changedInput schema / properties / adapterPath / descriptionAdded value: +"Optional explicit CodeLLDB executable path for codelldb/dump modes; omit to auto-discover it."Input schema / properties / analysis / descriptionAdded value: +"Hints used to distinguish project code from runtime, system, or third-party frames."Input schema / properties / analysis / properties / callerDepth / descriptionAdded value: +"How many project-controlled caller frames beyond the selected frame to inspect for provenance and root cause."Input schema / properties / analysis / properties / projectModules / descriptionAdded value: +"Optional executable or library names treated as project-controlled modules during frame selection."Input schema / properties / analysis / properties / projectRoots / descriptionAdded value: +"Optional local source-root paths used to recognize project-controlled stack frames."Input schema / properties / args / descriptionAdded value: +"Command-line arguments passed to the launched program in mode=codelldb."Input schema / properties / breakpoints / descriptionAdded value: +"Optional source breakpoints configured before a live/codelldb reproduction completes setup."Input schema / properties / breakpoints / items / descriptionAdded value: +"Source file and line breakpoints configured before a live reproduction runs."Input schema / properties / breakpoints / items / properties / lines / descriptionAdded value: +"One or more 1-based source line numbers to replace as breakpoints for this source file."Input schema / properties / breakpoints / items / properties / source / descriptionPrevious value: -"Absolute or adapter-resolvable source file path"New value: +"Absolute or adapter-resolvable source file path."Input schema / properties / configuration / descriptionAdded value: +"Required for mode=live: adapter-specific DAP launch/attach configuration."Input schema / properties / cwd / descriptionAdded value: +"Working directory for CodeLLDB/target launch and a project-root hint for diagnosis."Input schema / properties / dumpPath / descriptionAdded value: +"Required for mode=dump: local path to the native core/minidump file."Input schema / properties / env / descriptionAdded value: +"Environment variables supplied to the launched program in mode=codelldb."Input schema / properties / mode / descriptionAdded value: +"current inspects an existing stop; live runs launch/attach through an initialized DAP session; codelldb starts CodeLLDB and launches program; dump opens a frozen core/minidump."Input schema / properties / program / descriptionAdded value: +"Required for mode=codelldb; optional for dump symbol resolution. Local path to the native executable."Input schema / properties / request / descriptionAdded value: +"For mode=live, choose whether the initialized DAP adapter launches a target or attaches to an existing authorized target."Input schema / properties / requestTimeoutMs / descriptionAdded value: +"Per-request DAP timeout in milliseconds for CodeLLDB operations."Input schema / properties / snapshot / descriptionAdded value: +"Bounds and optional evidence categories for a runtime crash snapshot."Input schema / properties / snapshot / properties / disassembleAfter / descriptionAdded value: +"Number of instructions after the selected instruction to request."Input schema / properties / snapshot / properties / disassembleBefore / descriptionAdded value: +"Number of instructions before the selected instruction to request."Input schema / properties / snapshot / properties / includeDisassembly / descriptionAdded value: +"Include best-effort disassembly around the selected instruction pointer when supported."Input schema / properties / snapshot / properties / includeExceptionInfo / descriptionAdded value: +"Request structured exception information for the stopped thread when supported."Input schema / properties / snapshot / properties / includeModules / descriptionAdded value: +"Include a bounded list of loaded executable images and libraries."Input schema / properties / snapshot / properties / maxVariablesPerScope / descriptionAdded value: +"Maximum variables returned per inspected scope, bounding evidence size."Input schema / properties / snapshot / properties / moduleCount / descriptionAdded value: +"Maximum loaded modules to include when module collection is enabled."Input schema / properties / snapshot / properties / stackLevels / descriptionAdded value: +"Maximum number of stack frames to inspect when collecting crash evidence."Input schema / properties / snapshot / properties / threadId / descriptionAdded value: +"Stopped DAP thread to inspect; omit to use the session-selected stopped thread."Input schema / properties / sourceMap / descriptionAdded value: +"For mode=dump, map source paths stored in debug symbols to local source paths."Input schema / properties / stopOnEntry / descriptionAdded value: +"When true in mode=codelldb, request an initial debugger stop at program entry before normal execution."Input schema / properties / timeoutMs / descriptionAdded value: +"Maximum milliseconds to wait for the reproduction to stop, exit, or terminate."Input schema / properties / workflow / descriptionAdded value: +"Controls one-shot diagnosis, explicit verification, or the bounded autonomous crash workflow."Input schema / properties / workflow / properties / agentState / descriptionAdded value: +"Opaque autonomous state returned by the previous autonomous call; pass it back unchanged to continue the bounded cycle."Input schema / properties / workflow / properties / baseline / descriptionAdded value: +"Verification baseline returned by an earlier diagnosis; required when stage=verify."Input schema / properties / workflow / properties / maxIterations / descriptionAdded value: +"Maximum autonomous fix/reproduce iterations allowed when starting stage=autonomous."Input schema / properties / workflow / properties / stage / descriptionAdded value: +"diagnose creates initial evidence; verify compares against a prior verification baseline; autonomous advances the bounded agent state machine."v0.12.0debug_attachdebug_attach_codelldbdebug_codelldb_infodebug_data_breakpoint_infodebug_diagnose_stopdebug_disassembledebug_evaluatedebug_eventsdebug_exception_infodebug_launchdebug_launch_codelldbdebug_modulesdebug_open_dumpdebug_pausedebug_read_memorydebug_run_to_stopdebug_scopesdebug_set_breakpointsdebug_set_data_breakpointsdebug_set_exception_breakpointsdebug_set_function_breakpointsdebug_set_instruction_breakpointsdebug_set_source_breakpointsdebug_source_disassemblydebug_stackdebug_startdebug_start_codelldbdebug_stepdebug_this_crashdebug_threadsdebug_variablesv0.6.0debug_attachdebug_attach_codelldbdebug_codelldb_infodebug_continuedebug_data_breakpoint_infodebug_disassembledebug_disconnectdebug_evaluatedebug_eventsdebug_exception_infodebug_launchdebug_launch_codelldbdebug_modulesdebug_pausedebug_read_memorydebug_scopesdebug_set_breakpointsdebug_set_data_breakpointsdebug_set_exception_breakpointsdebug_set_function_breakpointsdebug_set_instruction_breakpointsdebug_set_source_breakpointsdebug_snapshotdebug_stackdebug_startdebug_start_codelldbdebug_statusdebug_stepdebug_threadsdebug_variablesScored across 14 tools
Each tool targets a distinct phase of debugging, but debug_this_crash, debug_diagnose_stop, and debug_snapshot overlap in stopped-crash analysis, and debug_find_writer/debug_trace_value are closely related. The detailed usage guidance largely prevents misselection.
All tools share the debug_ prefix and most use verb_object forms like compare_runs or find_writer, but noun-style names such as debug_sessions, debug_status, and debug_source_disassembly, plus debug_this_crash/debug_this_hang, break the pattern. The naming is still predictable enough to infer the domain.
14 tools is within the ideal range for a specialized debugging server, with each tool covering a distinct aspect: session management, run control, stopped-state inspection, postmortem analysis, and watch/trace workflows. No tool feels superfluous.
The surface provides strong coverage of the DAP debugging lifecycle: session creation/status/disconnect, run-to-stop and continue, snapshot and diagnosis, crash and hang workflows, dump analysis, differential comparison, and value-write tracking. For the evident native crash and hang diagnosis purpose, there are no critical missing operations.
Agent Replay Debugger MCP — record every agent step + deterministic replay. Step-debugger for
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
Live browser debugging for AI assistants — DOM, console, network via MCP.
Hosted MCP memory and agent control plane for durable conversations, jobs, and operations.
