x64dbg-mcp: Driving x64dbg and x32dbg from an AI Agent over JSON-RPC

What x64dbg-mcp actually exposes to an agent

x64dbg is a Windows debugger with a GUI, and its automation story has traditionally meant writing a plugin in C++ or scripting the built-in command language. x64dbg-mcp takes a different route: it embeds a Model Context Protocol server inside the debugger process and lets anything that speaks JSON-RPC 2.0 drive it over HTTP. The README frames the audience as "external applications and AI agents," and the feature list backs that up with 79 tools, 7 direct resources plus 8 resource templates, and 10 prompts.

The split between those three building blocks matters more than the counts. Tools are the mutating surface: run, pause, step, restart, read and write memory, allocate memory, touch 50-plus registers, manage software, hardware, memory, conditional and logging breakpoints, disassemble, resolve symbols, list and switch threads, walk the stack, dump modules, detect packers and OEPs, and execute x64dbg commands in batch. Resources are read-only context an application pulls on its own: debugger state, registers, modules, threads, memory map, breakpoints, stack. Prompts are the ten canned workflows, among them crash analysis, vulnerability hunting, function tracing, binary unpacking, algorithm reversing, string hunting, code patching and API monitoring.

That is a wide surface for a plugin, and the breadth is the point. The interesting question is not whether an agent can call a step function. It is whether the debugger's state survives the round trip, and the project addresses that with context snapshots: capture the debugging state, then compare two captures. That is the feature that makes an agent loop plausible rather than a sequence of blind commands.

Two transports, two generations of MCP clients

The plugin serves two endpoints. Streamable HTTP transport, which the README tags as MCP 2025-03-26, lives on /mcp. A legacy HTTP+SSE endpoint lives on /sse for older clients. Both are reached at http://127.0.0.1:3000 by default, and the server starts from the menu at Plugins then MCP Server then Start MCP HTTP Server.

Choosing between them is a client question, not a preference. If your MCP client was written against the 2025-03-26 specification, point it at /mcp. If it predates that and expects the older SSE handshake, point it at /sse. The README does not describe a compatibility shim that makes one endpoint behave like the other, so treat the two as separate integration paths and check which one your client documents.

The binding address is a second decision. The default is 127.0.0.1, which keeps the server on the loopback interface. Changing it to a routable address is possible through config.json, and the security block exists for exactly that case: origin_allowlist, host_allowlist, auth_enabled and auth_token. Authentication arrived in v1.0.11 as HTTP Bearer authentication, and the host allowlist in v1.0.9. The version history reads like a project discovering, release by release, that a debugger control plane is a sensitive thing to put on a socket.

Installing the plugin and making a first call

There is no package manager route here. The README gives a build script that detects vcpkg, pulls nlohmann_json, configures CMake for both architectures and copies the result into dist/. Windows 10 or 11, CMake 3.15 or higher, Visual Studio 2022 with the C++ Desktop Development workload, vcpkg and Git are the stated prerequisites.

git clone https://github.com/SetsunaYukiOvO/x64dbg-mcp.git
cd x64dbg-mcp
.\build.bat

The script produces dist\x64dbg_mcp.dp64 for 64-bit targets and dist\x32dbg_mcp.dp32 for 32-bit ones. Copy each into the matching plugin directory of your x64dbg installation, then restart the debugger.

copy dist\x64dbg_mcp.dp64 <x64dbg-path>\x64\plugins\
copy dist\x32dbg_mcp.dp32 <x64dbg-path>\x32\plugins\

The optional configuration file goes into a subdirectory next to the plugin, and the README uses different folder names for the two architectures: x64dbg-mcp under x64\plugins and x32dbg-mcp under x32\plugins. Skipping this step means the built-in defaults apply, which is worth knowing before you assume a permission is off.

mkdir <x64dbg-path>\x64\plugins\x64dbg-mcp
copy config.json <x64dbg-path>\x64\plugins\x64dbg-mcp\

After restarting, open a target, start the server from the Plugins menu, and the repository's examples directory gives you something to run against it: examples/python_client_http.py and examples/dump_demo.py. The README does not print the expected response for either script, so read them before running them rather than treating them as a documented quickstart.

Permissions default to closed, and that is deliberate

The shipped config.json disables memory writes, register writes and script execution, and enables breakpoint modification. It also carries an allowed_methods list containing the two wildcard patterns debug.* and memory.*. That combination is the most consequential thing in the repository, because it decides what an agent can do to a live process.

{
  "permissions": {
    "allow_memory_write": false,
    "allow_register_write": false,
    "allow_script_execution": false,
    "allow_breakpoint_modification": true,
    "allowed_methods": ["debug.*", "memory.*"]
  }
}

Read the allowed_methods entry carefully. An agent that only matches debug.* and memory.* cannot reach breakpoint methods at all, even though allow_breakpoint_modification is true. Two controls have to agree, and the README does not spell out the precedence between them. If a call you expect to succeed returns a permission error, check both places before assuming the plugin is broken.

Script execution is the setting to think hardest about. With allow_script_execution enabled, the agent can run x64dbg commands in batch, which is effectively arbitrary control of the debugger's own command surface. That is a large grant, and it is off by default for a reason. The v1.0.11 configuration editor, reached at Plugins then MCP Server then Edit Config, lets you change these values through pages for Server, Security, Permissions, Runtime and Logging instead of editing JSON by hand, and it preserves the version field and unknown future fields when saving.

Where the design bites back

The plugin lives inside a GUI process. That single fact explains most of its constraints. There is no headless mode described in the README, no service wrapper, and no Linux or macOS build: the prerequisites name Windows 10 or 11 and Visual Studio 2022, and the outputs are .dp64 and .dp32 files that only x64dbg and x32dbg load. If your targets are ELF binaries or your pipeline runs in containers, this project is the wrong tool and no configuration change fixes that.

Timeouts are a second rough edge. The config exposes request_timeout_ms at 30000, step_timeout_ms at 10000 and memory_read_timeout_ms at 5000. A step against a target that hits a long computation can exceed the step timeout, and the README does not describe what the caller receives when that happens. An agent that assumes a step always returns a fresh register state will misbehave on a slow target. Treat the timeout values as part of your integration contract and handle the failure path explicitly.

Authentication defaults to off: auth_enabled is false and auth_token is empty. On loopback that is defensible. The moment the address changes, the server is an unauthenticated control plane for a debugger, and the host and origin allowlists plus the Bearer token are the only things standing between it and anything that can reach the port. The README documents the settings but does not walk through a hardened remote deployment, so the burden of getting that right sits with you.

Finally, the project is young in release terms. v1.0.9 fixed a stack issue in x32dbg, v1.0.10 addressed architecture compatibility and browser CORS, v1.0.11 added authentication. Three patches in roughly six weeks, each closing a gap in a different area, tells you the surface is still settling.

x64dbg-mcp against scripting x64dbg directly

The obvious alternative is not another MCP server. It is the x64dbg script engine and the existing plugin ecosystem, or a purpose-built automation layer that talks to the debugger's own interfaces. Those approaches keep the logic inside the debugger: a script runs in the same process, with no HTTP hop, no JSON serialization and no permission layer to reconcile.

The difference in approach is where the intelligence sits. A script encodes a fixed procedure written by a human who already knows what to look for. x64dbg-mcp exposes the debugger as a set of typed tools and read-only resources so a model can decide the next call at runtime, which is the whole reason the prompts exist: crash analysis, function tracing, string hunting and the rest are templates for that decision loop. You are trading determinism for adaptivity.

That trade is not free. A script either works or fails visibly. An agent driving 79 tools can take a plausible-looking wrong path, set a breakpoint in the wrong place, or burn a step timeout, and you need the snapshot comparison feature to notice. If your task is a known, repeatable extraction, a script is cheaper and easier to audit. If your task is exploratory and you would otherwise be clicking through the disassembly view yourself, the MCP route earns its overhead.

Editorial conclusion

Adopt x64dbg-mcp if you already drive x64dbg or x32dbg by hand and want an agent or a Python script to do the repetitive part: reading registers, walking the module list, capturing snapshots. Do not adopt it if you need a Linux or macOS debugger, or if you expect a remote multi-user service, because the plugin runs inside a Windows GUI process and ships with authentication disabled. Before wiring it into anything automated, confirm three things: that your x64dbg build loads a .dp64 from the plugins directory, that config.json sits next to the plugin so the permission defaults actually apply, and which of the two transports (/mcp or /sse) your client speaks.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. SetsunaYukiOvO/x64dbg-mcp on GitHub