x64dbgMCP lets a language model drive the x64dbg debugger

A debugger behind a tool interface

x64dbgMCP is an MCP server that bridges various large language models, with Claude and Cursor tested, with the x64dbg debugger, providing direct access to debugging applications through prompts.

The mechanism is the Model Context Protocol. Instead of a human clicking through a debugger interface, the model gets a list of tools it can call, and each tool corresponds to a capability of the debugger. The feature list puts the count at forty or more x64dbg SDK tools, described as providing access to almost every single debugging feature given by the SDK for smart debugging.

The cross-architecture support is worth noting, because it is not a small detail. The plugin works with both x64dbg and x32dbg, and the README explains the practical consequence: the plugin ships as a .dp64 or a .dp32 file depending on the target, and the build produces both.

The third feature is described as API compatibility, meaning the server can be run from a command line using the arguments given in the Python file, so the same bridge that Claude Desktop talks to can be driven from a script or a terminal. That matters for reproducible analysis, where you want the same sequence of debugger commands to be re-runnable rather than retyped.

The project is GPL-3.0 licensed, the primary language is C++ because the plugin is a native debugger plugin, and the repository holds a CMakeLists.txt, a src directory, the licence file and a single documentation file describing a worked example.

What this is not is an automated vulnerability scanner. It is a way to give a model hands on a debugger, and the value and the risk both come from that.

Three steps: a plugin, a Python bridge, and a configuration entry

The quick setup is described in three steps, and each is small.

First is the plugin. You grab a .dp64 or a .dp32 file from the repository's build and release directory and copy it into your local x64dbg release plugins folder, that is the plugins directory inside the release/x64 directory of your x64dbg installation.

Second is the bridge. You copy the x64dbgmcp.py file from the repository's src directory, install the mcp and requests packages with pip, and then point your local claude_desktop_config.json at that file.

Third is running it. You launch x64dbg, you start Claude Desktop, and you check that the plugin loaded successfully, with the note that the x64dbg log is available with ALT+L.

That last step is the one people skip, and it is the reason the README mentions the key combination. A bridge that cannot reach the debugger looks exactly like a model that is not helping, and the log is where you find out whether the plugin side or the client side is at fault.

The steps assume a Windows machine, because x64dbg is a Windows debugger, the plugin format is a Windows plugin, and the configuration example uses Windows path separators.

The configuration file is the whole integration surface

The bridge is registered the way any MCP server is, and the configuration is a single JSON object in the desktop client's config file.

{
  "mcpServers": {
    "x64dbg": {
      "command": "Path\\To\\Python",
      "args": [
        "Path\\to\\x64dbg.py"
      ]
    }
  }
}

The shape is the standard one, a server name, the command that starts it and the arguments it is started with. Here the command is the path to a Python interpreter and the argument is the path to the bridge script, so the Python installation is chosen by you rather than taken from the path, which is the detail that makes the setup work on a machine with several interpreters.

There is no host, no port and no token in this configuration, because the two sides are not talking over a network. The bridge starts a process, the plugin inside the debugger connects back to it, and the MCP protocol runs over that local channel. That is a much smaller attack surface than a network service would be, and it is also why the debug step above matters: if the debugger is not running with the plugin loaded, nothing is listening.

For clients other than Claude Desktop, the same idea applies, since the third feature is that the server can be run from a command line with the arguments given in the Python file, and the README notes that Cursor is tested as well.

Building the plugin yourself, and getting both architectures at once

The README notes that the features listed are the ones you get by building from source, and that CMake and MSVC should be installed and on the path.

The build sequence is four commands. You clone the repository, you change into the cloned directory, you configure with CMake, and you build.

- git clone https://github.com/wasdubya/x64dbgmcp
- cd x64dbgmcp
- cmake -S . -B build     (will resolve the pluginsdk automatically, so no need to worry about dependencies.)
- cmake --build build --target all_plugins --config Release     (will build both 32 and 64 bit versions of the plugin)

Two details are worth pulling out. The configure step resolves the plugin SDK automatically, so you are not expected to install or point at the x64dbg SDK yourself, which removes the most common source of friction in building a debugger plugin. And the all_plugins target is what produces both the 32-bit and the 64-bit plugin, which is what you want if you analyse both 32-bit and 64-bit samples.

If you only need one architecture, the README gives the alternative. You configure a separate build directory with the Win32 generator and turn the both-architectures build off:

- cmake -S . -B build32  -A Win32 -DBUILD_BOTH_ARCHES=OFF
- cmake --build build32 --config Release

So the build matrix is a command line switch rather than a separate project, and the same CMakeLists.txt drives both. The build artefacts land in the build and release directory, which is the same place the quick setup tells you to copy the plugin files from, so the loop from building to testing is short.

Using it well, and the advice the README gives for free

The usage section shows two example prompts, and they are the right starting points because they are the two things a debugger is for.

The first asks what the current value of the RAX and RIP registers is, which is register inspection. The second asks to find the pattern 48 8B 05 in the current module, which is pattern searching, and pattern searching is the operation that most benefits from being expressed as text rather than typed into a dialog.

The repository also includes a worked example document for Cursor, an Opus 4.5 session looking for the process environment block, which is a more substantial use case and shows the kind of multi-step reasoning the tools support.

Then there is the advice, and it is the most practically useful part of the README. If you do not provide the model with the context of where your executable is, it will not have the capability to restart the binary if it crashes or hangs, so you should give it the full path of the binary so it can call the command execution function with an init command pointing at an absolute path. GetModuleBase is the best place to start for models, so they query for the right addresses, because x64dbg will not respond to addresses that are out of range.

Those are debugging lessons dressed up as prompt guidance. The model needs to know the module layout before it can read memory, and it needs to be able to restart the process before it can handle a crash.

The last tip is about cost rather than correctness. If the token count is a concern, the README suggests Headroom, a proxy to put between the plugin and the language model's MCP Python agent. Debugging sessions generate a lot of output, and a proxy that trims it is a practical mitigation for long sessions.

What this gives you, and what it costs you

Three properties of the design are worth weighing before you connect a model to a live process.

The first is reach. Forty or more debugger functions, including memory reads, disassembly and command execution, are available to a model that can act on its own suggestions. That is what makes the tool useful, because a model that can only read register values will not get you through a reversing session. It is also the reason to run it on a sample, in a controlled environment, rather than attached to something that matters.

The second is the local channel. The bridge and the plugin talk over a local connection with no network port, and the configuration has no credentials to leak. That is a genuine advantage over a web service, and it is a direct consequence of the plugin model.

The third is the release naming, which is a small sign of an early-stage project. The published releases are build1.1 from 2026-03-15, v1.0.0 from 2026-02-13, and a pre-compiled plugin and MCP bridge release from 2026-01-29. Three different naming conventions in three months suggests the release process is still settling, so do not build a workflow that assumes a stable tag scheme.

The last push was on 2026-06-05, the repository is not archived, and the whole thing is a few files, so the project is small and readable. That cuts both ways: it is easy to audit a few thousand lines of plugin code, and it is also easy for the tool surface to change under you when the debugger's SDK moves.

Editorial conclusion

x64dbgMCP fits a reverse engineer or malware analyst who wants an assistant to query registers, search for byte patterns and script the debugger instead of clicking through it, and it does not fit a developer who only wants a debugger, since the plugin and the bridge add a component that can execute commands against a live process. Before you connect a model to a debugger, read the README guidance about handing over the executable's full path and about starting with GetModuleBase, because the model will otherwise query addresses the debugger cannot answer. Note that the plugin is built with CMake and MSVC, so the toolchain is Windows only, and the project is GPL-3.0 licensed with the last push on 2026-06-05.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. Wasdubya/x64dbgMCP on GitHub