Skip to main content
Most debugger operations are scoped by session_id. Create or pick a session first, then load a binary or attach to a running process.
Except for create_debug_session and list_debug_sessions, the debugger tool family expects an existing session. Use explicit session names for every serious workflow.

Session lifecycle tools

Load, attach, and raw command tools

Common debugger parameters

string
required
Debug session to operate on. Required for nearly every debugger tool on this page.
string
Target binary path. Use a path that resolves under /workspace.
string
Breakpoint or jump target, such as a symbol, file:line, or address expression.
string
Raw GDB or pwndbg command for execute, or a stepping verb such as c, n, s, ni, or si for step_control.
string
Argument string passed to the inferior when using run.
number
Target process id for attach.

Execution control tools

Typical flow

1

Create the session

2

Load the binary and stop at main

3

Inspect and continue

Common edge cases

Create the session first with create_debug_session, then pass the same session_id on all later calls.
Load a file with set_file before calling run, or pass binary_path where the tool supports it.
The MCP attach tool returns the attach result plus a context snapshot list. If you want a single wrapper object instead, use the attach sidecar API described in Attach API.

Common debugger response fields

boolean
required
Whether the tool call succeeded.
string
Session that the tool actually operated on.
string
Current debugger or inferior state after the operation, when provided by the backend.
string
Resolved binary path after set_file or other file-sensitive operations.
string
Session-specific runtime directory returned by get_session_info.
string
Short actionable error message when the call fails.
string
Exception type returned by the shared error wrapper on failures.