Pause execution at a specified address by setting a software or hardware breakpoint in an active debug session, enabling inspection of program state at that point.
Set a software breakpoint at the specified address in the debugged process.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Hex address for the breakpoint (e.g. "0x08048000") | |
| hardware | No | Use hardware breakpoint instead of software | |
| session_id | Yes | Debug session ID |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only names the action without explaining that breakpoints persist, that software breakpoints patch process memory, that the hardware parameter changes the mechanism, or what happens with invalid addresses. For a mutating debugger operation, this is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, and the action and target are front-loaded. It is appropriately concise, though the omission of the hardware behavior means some useful information was sacrificed for brevity.
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 annotations, no output schema, and a state-changing operation, a one-sentence description is not operationally complete. An agent can fill the parameters from the schema but cannot predict return values, failure modes, session prerequisites, or cleanup behavior. Additional context about hardware mode and session state would be needed for a safe call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter semantics: 'address' is already documented, and session_id and hardware are only described in the schema. It does not provide any additional context about how the parameters interact or when hardware should be true.
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 clear verb and resource: set a breakpoint at a specified address in a debugged process, and it is distinguishable from debug_remove_breakpoint and debug_list_breakpoints. However, it says 'software breakpoint' while the schema exposes a hardware flag, so it narrows the tool's actual scope and could mislead an agent into thinking hardware breakpoints are unsupported.
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?
There is no explicit guidance on when to use this tool versus alternatives, nor any mention of prerequisites such as an active debug session. The phrase 'debugged process' and the session_id parameter imply a session must exist, but the description never states this or explains that breakpoints should be removed via debug_remove_breakpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.