AI NewsOpen sourceAnnouncement
An MCP server for x64dbg gives AI assistants 84 debugger tools
A new Zig plugin makes x64dbg controllable by any MCP-compatible AI assistant, exposing 84 debugger tools including breakpoints, memory reads, register dumps and pattern scans over authenticated HTTP.
Image: GitHub
Why it mattersReverse-engineering work that used to take hours of manual stepping can now be done by an AI assistant that reads memory, sets breakpoints and disassembles, on the reader's own binary.
A new open source plugin gives any Model Context Protocol client full control of x64dbg, the widely used Windows debugger. The repository, duty1g/x64dbg-mcp-server, was created on 22 August and has 1,824 stars, 186 forks and 18 commits in the ten days since. It is licensed MIT and built in Zig, which the README states gives a zero-dependency single-binary output delivered as native .dp32 and .dp64 debugger plugins.
What the plugin exposes
The README lists 84 MCP tools that map directly onto debugger operations: breakpoint management (SetBreakpoint), memory reading and writing (ReadMemory), register inspection (GetAllRegisters), disassembly (Disassemble), thread control, module analysis (DumpModule), pattern scanning and symbol search. Two transports are supported: HTTP with JSON-RPC and Server-Sent Events, both behind Bearer token authentication.
The README's own worked example loads calc.exe, sets a breakpoint, reaches it, reads registers and memory, and single-steps through instructions, with each action issued as an MCP tool call rather than a manual click in the x64dbg UI.
Who the clients can be
The project says only that it works with "any MCP-compatible AI assistant" and "any MCP client", without naming Claude Desktop, Cursor or the others by name. The MCP specification is the contract, so anything that supports it can control the debugger. The choice of authentication is a Bearer token, which means the debugger is not exposed by default and a caller has to be given the token before it can attach.
Reading the state of a running process
Debugger work is one of the tasks where an AI assistant has genuinely little to offer if the model can only read the source code. Reverse engineering, native crash triage, malware analysis, and driver work all depend on the state of a running process: the registers at the fault, the memory at an address, the disassembly around a call. This plugin gives an assistant access to that state, so an engineer can ask it to step through the crash instead of doing it themselves.
For a security team the benefit is speed on repetitive stepping and pattern searching. For a working developer the closer parallel is the effect that language servers had on refactoring: the assistant can now see the real state the debugger sees, and act on it.
Two limits are worth stating. The plugin is Windows only, because x64dbg is. And giving an AI assistant the ability to write memory in a debugged process is the same risk as giving a person that ability. The Bearer token check is the sensible default, and the token belongs on a machine the assistant runs on, not on the internet.
Source
This item was written by an AI system from the linked source. Reveneau is responsible for what it publishes.
Get AI News in your inbox
New developer tools, model and agent releases, and how teams are actually using them to release software. Short, and only when there is something worth reading.