Handing an AI Assistant the Controls of x64dbg

Reading the README for x64dbg-mcp-server, the line I keep coming back to sits in the Authentication section, not the tool list: the server "has full debugger control and can read/write process memory," so every request needs a valid token. That sentence frames what it means to connect an AI assistant to a live debugger, and it is where anyone deploying this should start.

What the assistant gets

The project is a native MCP plugin for x64dbg that, per the README, exposes the debugger's full functionality over HTTP. It is written in Zig, and the README describes it as having zero dependencies and single-binary output that cross-compiles to both x32 and x64. It speaks MCP 2024-11-05 over Streamable HTTP and SSE, with JSON-RPC 2.0.

The README gives two different tool counts. The Features list says "84 MCP Tools" and "22 Event Callbacks," while the Tools section opens with "72 MCP tools covering the full x64dbg debugging workflow." The README also documents a ListCommandsByCategory tool that lists available MCP tools, so I would trust what the running server reports over either number.

The tool tables split into two groups. A small set is always available, including GetDebugState, LoadBinary, AttachProcess, and ExecuteDebuggerCommand, which the README describes as "Run any x64dbg command." The larger group requires an active debug session and covers stepping, several breakpoint types, registers, threads, modules, memory maps, imports and exports, pattern scanning, xrefs, PE analysis, and tracing.

Several of those tools change state rather than observe it. SetRegister sets a CPU register value. WriteMemToAddress patches memory with hex bytes, and RestorePatches restores the original bytes. AllocateMemory and FreeMemory act on the target process. Assemble assembles an instruction at an address. DumpMemory and DumpModule save data to files on disk.

The README's example session shows how this feels in practice. A user asks to load calc.exe and break at the entry point, and the assistant calls LoadBinary, SetBreakpoint, run, and WaitForPause. From there it reads registers, dumps bytes at the instruction pointer, and steps over instructions on request. The assistant can control x64dbg and read or write process memory, and the access controls deserve the same attention you would give any remote administration interface.

How the README says access is protected

The README documents bearer authentication as mandatory. A token is auto-generated on first run and required on every request, and requests without a valid token receive 401 Unauthorized. Clients send it as an Authorization: Bearer <token> header, and both sample client configs in the Usage section include that header.

Token management lives in the plugin's config dialog, under Plugins > x64dbg-MCP Server > Configure MCP Server... There, Generate rotates the token and Copy puts it on the clipboard. The same dialog changes the bind address and port, and the README says the server auto-restarts on save. Config is persisted to mcp_config.json next to the x64dbg executable.

Settings to review before connecting anything

The Install section lists the default listeners as 0.0.0.0:9094 for x64 and 0.0.0.0:9095 for x32. The Configuration section explains the options: 0.0.0.0 listens on all interfaces for WSL or remote access, while 127.0.0.1 is local-only. If your assistant runs on the same Windows host and you have no WSL or remote client, the local-only setting matches that setup, and changing it is a config dialog edit.

A few habits follow from what the README describes. Treat mcp_config.json with care, since the dialog that writes it also manages the auth token. The README's client examples use http:// URLs, so if traffic leaves the machine, consider which network it crosses.

The Features list also says the MCP server starts automatically when x64dbg launches. Opening the debugger for an unrelated task still brings the listener up, which is one more reason to set the bind address deliberately.

Building it

The README requires Zig 0.16-dev or later and says it builds on Windows, WSL, Linux, or macOS. The build command is:

zig build -Doptimize=ReleaseSafe --prefix dist

The output mirrors x64dbg's folder structure, producing x64dbg-MCP-Server.dp32 under dist/x32/plugins/ and x64dbg-MCP-Server.dp64 under dist/x64/plugins/. Copying the contents of dist/ into the x64dbg root deploys both architectures at once.

GitHub: https://github.com/duty1g/x64dbg-mcp-server

Curated by Agent Palisade — practical AI for small and mid-sized businesses.