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

The gap x64dbg-mcp fills between a debugger and an agent

x64dbg is a Windows GUI debugger. Its scripting works, but it lives inside the debugger window and it is written for a human at a keyboard. An AI agent or an external tool has no supported way to say "set a breakpoint here, run, then read RCX" without someone building the transport first. This plugin is that transport. It compiles into x64dbg_mcp.dp64 for x64dbg and x32dbg_mcp.dp32 for x32dbg, and once loaded it exposes the running debugger as a Model Context Protocol server over HTTP on port 3000 by default. The audience is narrow and specific: reverse engineers who already use x64dbg on Windows and want an agent, a script, or another program to drive the session. It is not a debugger. It does not analyse anything on its own. It is a control surface, and the README is explicit that it is meant for remote debugging through a JSON-RPC 2.0 interface.

What the MCP surface actually exposes

The README lists three MCP building blocks. Tools number 79 and are the ones an agent invokes: execution control (init, run, pause, step, run_to, restart, stop), memory read/write/search/allocate, register access covering 50 or more registers across GPR, SSE and AVX, breakpoint management for software, hardware, memory, conditional and logging breakpoints, disassembly and symbol resolution, thread management, stack trace and analysis, module and memory dumping with packer and OEP detection, script execution for x64dbg commands and batch operations, and context snapshots that capture and compare debugging state. Resources are read-only and application-controlled: 7 direct resources (debugger state, registers, modules, threads, memory map, breakpoints, stack) plus 8 templates for memory content, disassembly, module info, symbol resolution and function analysis. Prompts are 10 workflow templates covering crash analysis, vulnerability hunting, function tracing, unpacking, algorithm reversing, execution comparison, string hunting, code patching, API monitoring and session initialization. The distinction matters when you wire up a client: tools mutate state, resources do not, and prompts are text the user drives rather than the model.

Transport, ports and the two protocol paths

The server speaks JSON-RPC 2.0 over HTTP. Two endpoints exist. Streamable HTTP transport per MCP 2025-03-26 is served on /mcp, and a legacy HTTP+SSE endpoint is served on /sse for older clients. That dual path is a pragmatic choice: MCP clients have moved at different speeds, and a plugin that only shipped the newer transport would strand anyone on an older SDK. The default bind address is 127.0.0.1 and the default port is 3000, both set under the server key in config.json. Nothing in the supplied material suggests the plugin ships a TLS terminator, so the transport is plain HTTP. That is fine for loopback and questionable the moment you point address at a non-loopback interface, which is presumably why later releases added a host allowlist and bearer authentication.

Building and installing the plugin

The prerequisites are Windows 10 or 11 on a 64-bit host, CMake 3.15 or higher, Visual Studio 2022 with the C++ Desktop Development workload, vcpkg and Git. The quick path is the build script. Clone the repository, then run .\build.bat for both architectures, or .\build.bat --x64-only, .\build.bat --x86-only, or .\build.bat --clean for a full rebuild. According to the README the script detects the vcpkg installation, downloads nlohmann_json, configures CMake for each architecture, builds with Visual Studio using parallel compilation, and copies output into dist/. The expected artefacts are dist\x64dbg_mcp.dp64 at roughly 837 KB and dist\x32dbg_mcp.dp32 at roughly 800 KB. The manual route is more instructive about what the build actually needs: cmake -B build_x64 -G "Visual Studio 17 2022" -A x64 with -DCMAKE_TOOLCHAIN_FILE pointing at vcpkg.cmake, -DVCPKG_TARGET_TRIPLET=x64-windows and -DXDBG_ARCH=x64, then cmake --build build_x64 --config Release. The x86 build swaps -A Win32, the x86-windows triplet and -DXDBG_ARCH=x86. Installation is a file copy into the debugger's plugins directory, x64\plugins\ for the 64-bit plugin and x32\plugins\ for the 32-bit one, followed by a restart of x64dbg or x32dbg.

Configuration keys that decide how much damage an agent can do

The config.json shown in the README is the most consequential part of the project. Under permissions, allow_memory_write, allow_register_write and allow_script_execution all default to false, while allow_breakpoint_modification defaults to true. allowed_methods is a pattern list, shown as ["debug.*", "memory.*"], which implies glob-style method filtering rather than an explicit method-by-method list. Under security there is origin_allowlist, host_allowlist, auth_enabled and auth_token, with authentication off by default. Under timeout there are request_timeout_ms at 30000, step_timeout_ms at 10000 and memory_read_timeout_ms at 5000, which tells you the author expected stepping and memory reads to be the operations that hang. Under features, enable_notifications, enable_heartbeat with a 30 second interval, and enable_batch_requests are all on, while auto_start_mcp_on_plugin_load is off, so the server does not listen until someone picks Plugins, then MCP Server, then Start MCP HTTP Server. Release v1.0.11 added an in-debugger configuration editor under Plugins > MCP Server > Edit Config, with pages for Server, Security, Permissions, Runtime and Logging. The README states it covers every runtime setting in the example config and preserves the version field and unknown future fields when saving.

Where this design gets in your way

The plugin only exists inside a running GUI debugger. There is no headless mode in the material, and auto_start_mcp_on_plugin_load is false, so an automated pipeline still needs x64dbg open and the menu item clicked, or that flag flipped in config.json first. That is a real constraint for CI, where a GUI debugger is awkward to host. Second, the default posture is restrictive in a way that will surprise people who skim: an agent that tries to patch a byte in memory or change a register will be refused until you edit permissions, and the failure will look like a broken tool rather than a policy decision. Third, the security defaults are permissive in the other direction. auth_enabled is false and both allowlists are empty, so the loopback bind address is doing all the work. Anyone who changes server.address to a routable interface without also setting auth_enabled and filling host_allowlist has exposed debugger control, which includes arbitrary memory writes and script execution, to whatever can reach the port. The release history shows the author closing this gap incrementally (v1.0.9 added the remote host allowlist, v1.0.10 added browser CORS handling, v1.0.11 added bearer authentication), which is a good sign but also a sign that the hardening arrived after the first releases.

How it compares to scripting x64dbg directly

The obvious alternative is x64dbg's own command and script interface, which the plugin itself exposes through its script execution tool. The difference is who holds the loop. A script is a fixed sequence written in advance: you know the addresses, you know the order, and it runs to completion. An agent driving 79 tools decides the next call from what the previous call returned, which is what you want for unpacking or crash triage where the path is not known ahead of time. The cost is that a script is reproducible and an agent session is not, so a finding produced through the MCP surface needs the transcript kept if anyone else is going to check it. There is also a middle option the README implies but does not develop: use the resources (debugger state, registers, modules, threads, memory map, breakpoints, stack) as read-only context feeds while keeping the mutating tools disabled, which gets you agent-assisted inspection without handing over write access.

Licence, maintenance and what to verify

The repository is MIT licensed, which permits commercial use and modification provided the copyright notice and permission notice are retained. That is a permissive licence and it also means no warranty, so the plugin is offered as-is. On maintenance cost, the release cadence visible in the material is roughly monthly across v1.0.9, v1.0.10 and v1.0.11 between July and August 2026, and each of those releases changed security-relevant behaviour: remote host allowlist, browser CORS, bearer authentication. If you depend on this, budget for re-reading config.json on upgrade, because a security default that flips between versions can silently change whether your client connects. The build itself is a standing cost: Visual Studio 2022, vcpkg and a CMake configure per architecture, and the plugin binaries are architecture-matched, so a 32-bit target needs the x86 build installed alongside the x64 one. Before relying on it, verify three things yourself: that the plugin loads into your x64dbg version at all, that the endpoint your client speaks (/mcp or /sse) matches what the plugin serves, and that the permission flags in your config.json reflect what you intend the agent to be able to do.

Editorial conclusion

Adopt x64dbg-mcp if you already script x64dbg by hand and want an agent to drive the same session through /mcp, and if you are willing to keep allow_memory_write, allow_register_write and allow_script_execution at false while you learn what the agent actually calls. Skip it if your targets are Linux or macOS binaries, if you need a headless debugger, or if you cannot install Visual Studio 2022 and vcpkg on the analysis host. Before trusting it, build with .\build.bat --x64-only, confirm the plugin loads, start the server, and read the first entries in x64dbg_mcp.log to see which methods the client actually invokes.

Official sources

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