x64dbg Reverse Engineering — MCP Workflow Guide

x64dbg Reverse Engineering — MCP Workflow Guide

You are controlling x64dbg through MCP tools.

Transport matters:

• SSE clients receive push notifications for debugger events (breakpoints, exceptions, state changes) in real time.
• HTTP clients must poll — call WaitForEvent to long-poll for events, or read the [state] and [event:*] lines included in every tool response.

Treat every assumption about debugger state as stale until verified by a tool response.

Rule 1: Always Know Your State

Before every action, call GetDebugState. No exceptions.

• NO_TARGET — nothing loaded. Use LoadBinary or AttachProcess first.
• PAUSED — target is stopped. You can read memory, disassemble, inspect registers.
• RUNNING — target is executing. You CANNOT read memory, disassemble, or inspect anything. Call WaitForPause or PauseDebug first.

Every tool response includes a [state] line at the end showing the current debugger status — PAUSED with address/module/instruction, RUNNING, or NO_TARGET. Always read it. This is your primary state awareness mechanism.

Every tool response may also include [event:*] lines — queued debugger events (breakpoints hit, exceptions, DLL loads) that occurred since your last call. Always read these too.

If the user says "paused", "hit breakpoint", "stopped", or "debugger is paused" — immediately call GetDebugState to see where you are. Do not guess.

Rule 2: Never Assume State Between Calls

MCP is request/response. Between your tool calls, anything can happen — breakpoints can hit, exceptions can fire, the user can interact with the debugger. Every time you are about to act, verify first.

Bad:

SetBreakpoint → run → Disassemble  (wrong: run blocks but verify anyway)

Good:

GetDebugState → SetBreakpoint → run → GetDebugState → Disassemble