x64dbg-mcp-server: Driving x64dbg From an MCP Client
x64dbg-MCP Server is a native MCP (Model Context Protocol) plugin for x64dbg that exposes the debugger's full functionality over HTTP. Connect any MCP-compatible AI assistant and control x64dbg programmatically: set breakpoints, step through code, read memory, dump registers, and more. Built with Zig — zero dependencies, single-binary output, cros
At a glance
- What is it?
- A Zig-built x64dbg plugin that exposes the debugger over HTTP with bearer-token auth, so an MCP-capable assistant can set breakpoints, step, and read memory. The design is sound for local agent workflows, but the README's own tool count already disagrees with itself.
- Who is it for?
- Adopt it if you already live in x64dbg and want an MCP client to drive breakpoints, stepping and memory reads without writing a plugin per task. Skip it if your analysis pipeline is headless, Linux-side, or driven by a framework that already ships its own debugger backend.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Zig, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap between an AI assistant and a live debugger
An assistant that can read assembly has no way to act on it. It can suggest a breakpoint address, but it cannot place one. That is the gap this plugin targets: x64dbg holds debugger state, and an MCP client holds the reasoning, but nothing connects them. The README frames the project as a native MCP plugin for x64dbg that exposes the debugger's full functionality over HTTP, letting a compatible assistant set breakpoints, step through code, read memory and dump registers. The intended user is someone doing reverse engineering or malware analysis who wants conversational control of a session rather than a script per task.
The plugin is written in Zig and cross-compiles to both x32 and x64 from any host, which the README lists as a feature: no .NET, no Python, no runtime. That matters because x64dbg plugins normally inherit the constraints of whatever language wraps the SDK. A single binary dropped into the plugins folder keeps the deployment story to one step. The repository topics point at the same audience: ai-debugging, malware-analysis, reverse-engineering, claude-code. This is not a general-purpose debugging library. It is a bridge for one specific pairing.
Plugin, HTTP server, JSON-RPC: where each piece sits
The architecture is a three-layer stack inside the debugger process. The plugin loads into x64dbg and starts an HTTP server automatically on launch. That server speaks JSON-RPC 2.0 and implements the MCP 2024-11-05 revision with two transports, Streamable HTTP and SSE. MCP tool calls arrive over one of those transports and are translated into x64dbg operations: LoadBinary, SetBreakpoint, ReadMemory, GetAllRegisters and the rest.
State flows in both directions. Tool calls are request-response, but the debugger is asynchronous. A target pauses when it wants to, not when the client asks. The README addresses this with a long-poll tool, WaitForEvent, described as blocking for debugger events such as breakpoint, pause, resume or exception, plus a separate WaitForPause that blocks until the target pauses. Alongside those, 22 event callbacks cover init, stop, breakpoint, exception, step, attach and detach, DLL load and unload, and thread events, feeding an event log that clients read through GetEventLog.
That event log is the part worth noting. Without it, an assistant would have to poll debugger state and guess what happened between calls. With it, the client can ask what occurred and then decide what to do next. The design assumes the assistant is doing the sequencing, and the plugin's job is to make every debugger transition observable.
Installing the plugin and pointing a client at it
Installation is a copy operation. The README says to copy the contents of dist/ into your x64dbg root folder, which deploys both the x32 and x64 builds, then launch x64dbg. The server starts on its own. Default bindings are 0.0.0.0:9094 for x64 and 0.0.0.0:9095 for x32.
Client configuration is a JSON block in something like .mcp.json. For Streamable HTTP, which the README recommends, the entry sets type to http, url to http://localhost:9094/, and an Authorization header carrying a bearer token. Legacy clients use type sse and the url http://localhost:9094/sse, with the same header. The token is generated on first run and is required on every request; the README describes bearer auth as mandatory. A config dialog under the Plugins menu lets you change IP, port and token, and the server restarts automatically when you save.
Two operational details follow from that. The bind address defaults to 0.0.0.0, so the server listens on all interfaces unless you change it in the dialog. And the README notes that connecting from WSL or a remote machine requires using the host's IP address and setting the bind address to 0.0.0.0. The README does not state where the generated token is stored on disk, so if you need to know its file path or permissions, that is something to confirm yourself rather than assume.
What the tool surface actually covers
The README splits tools into those always available and those requiring an active debug session. The always-available group includes GetDebugState, LoadBinary, ExecuteDebuggerCommand, ListCommandsByCategory, SearchForStrings, GetEventLog, ClearEventLog, EvalExpression, AttachProcess, Echo and WaitForEvent. The session group covers disassembly (Disassemble, DisassembleFunction), memory reads, execution control (run, StepInto, StepOver, StepOut, PauseDebug, StopDebug, RestartDebug), and a breakpoint set that goes beyond the basics: SetBreakpoint, SetHardwareBreakpoint with DR0 through DR3 for read, write or execute, SetConditionalBreakpoint with a condition expression and optional log, plus enable, disable, toggle, delete, delete-all and ResetHitCount.
ExecuteDebuggerCommand is the escape hatch. It runs any x64dbg command, which means the plugin does not have to model every debugger capability as a typed tool. The named tools exist for the common path; the command passthrough covers the rest. That is a reasonable split, though it shifts responsibility onto the client to know x64dbg's command syntax.
The feature list also mentions pattern scanning, string extraction, xrefs, symbols, bookmarks, PE analysis, OEP detection, module dumping, PEB and SEH inspection, and tracing. Those are listed as capabilities rather than documented tool signatures in the material available, so treat the specific call names as unverified until you check ListCommandsByCategory against your build.
The 84-versus-72 discrepancy, and other things the README does not settle
The README contradicts itself on scope. The features section claims 84 MCP tools. The Tools section header says 72 MCP tools covering the full x64dbg debugging workflow. Both numbers appear in the same document, and the tables below the second figure are partial, so neither can be reconciled from the text alone. That is not a fatal problem, but it is the kind of thing that should have been caught before release, and it means the tool inventory is the first thing to verify rather than trust.
A second unaddressed area is failure behaviour. The README states that session-dependent tools require an active debug session, but does not describe what a client receives when it calls StepOver with nothing loaded. Whether that is a JSON-RPC error, a tool-level error message, or a silent no-op determines how an assistant recovers, and the material does not say. Similarly, there is no discussion of concurrency: what happens when two MCP clients connect to the same port, or when a client issues a tool call while the target is running and the call requires a paused state. The WaitForPause and WaitForEvent tools suggest the intended pattern is to block rather than to race, but the enforcement is not described.
There is also no stated rate limit or request size limit. ReadMemory takes a size, and nothing in the material bounds it. On a large process, a careless client could ask for more memory than it means to.
Where this fits against scripting x64dbg directly
The obvious alternative is x64dbg's own scripting and its existing plugin ecosystem, where a script or a compiled plugin performs the same breakpoint and memory operations without an HTTP layer or an AI client. The difference is who decides the next step. In a script, the sequence is fixed before execution: break here, dump this, continue. With this plugin, the sequence is chosen at runtime by the MCP client, which can read the disassembly it just received and pick a different address.
That flexibility has a cost. A script is deterministic and reproducible; an assistant-driven session is neither, and the transcript is the only record of what happened. For analysis you need to repeat, a script remains the better tool. For exploration where you do not yet know what you are looking for, the plugin's model fits better. The comparison is not about capability, since both can reach the same debugger operations through ExecuteDebuggerCommand. It is about whether the control flow is authored in advance or decided turn by turn.
Licence, build and maintenance considerations
The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive arrangement and it is compatible with shipping the plugin inside a larger toolchain, but this is not legal advice and the LICENSE file in the repository is the authority.
Maintenance cost is mostly the Zig toolchain. The README advertises cross-compilation from Linux, macOS or WSL to Windows plugins, which means a build on a non-Windows host is a supported path rather than an accident. If you build from source, you are tracking Zig's compiler, and Zig's release cadence has historically included breaking changes, so a pinned compiler version is the practical approach. The release history shows v1.1 and v1.2 on the same day and v1.3 six days later, which suggests rapid iteration at the time of writing. Fast releases are not inherently a problem, but they do mean the documented tool list can drift from the binary you have installed. If you depend on a specific tool name, check it against your build rather than the README.
Editorial conclusion
Adopt it if you already live in x64dbg and want an MCP client to drive breakpoints, stepping and memory reads without writing a plugin per task. Skip it if your analysis pipeline is headless, Linux-side, or driven by a framework that already ships its own debugger backend. Before trusting it, verify the actual tool count behind ListCommandsByCategory against the README's 84-versus-72 discrepancy, confirm the generated token file's permissions, and decide whether binding 0.0.0.0 is acceptable on your network.
Community notes