x64dbg-MCP Server: driving x64dbg from an AI assistant over HTTP

What x64dbg-MCP Server actually solves

x64dbg has a scripting engine and a command bar. Neither is conversational. If you want an AI assistant to set a breakpoint, read a register, dump memory and then decide what to do next, you normally write glue code that shells into the debugger and parses text. This project removes that glue by putting an MCP server inside the debugger process.

The README describes it as a native MCP plugin for x64dbg that exposes the debugger's full functionality over HTTP, so any MCP-compatible assistant can set breakpoints, step through code, read memory and dump registers. The audience is narrow and identifiable: reverse engineers and malware analysts who already use x64dbg interactively and want an agent to operate the same session, rather than a separate analysis pipeline. The topics list on the repository points at malware analysis and binary analysis, which matches that reading.

What it is not: a standalone debugger, a library you link against, or a service that runs without x64dbg. The plugin starts when x64dbg starts, and the tools act on the session you have open. If your goal is automated triage of thousands of samples on a build server, this design is the wrong shape, because there is no documented headless mode.

How the plugin is wired: HTTP transports, JSON-RPC and a token

The mechanism is straightforward once you see the pieces. x64dbg loads the plugin, the plugin opens an HTTP listener, and MCP clients speak JSON-RPC 2.0 to it. The README states support for MCP 2024-11-05 with Streamable HTTP and SSE transports. Streamable HTTP is the recommended path; SSE exists for legacy clients.

Ports are fixed by default: x64 listens on 0.0.0.0:9094 and x32 on 0.0.0.0:9095. Both bind to all interfaces, which is convenient from WSL or a remote host and also means the listener is reachable from the network unless you narrow the bind address in the config dialog. The README's own note about connecting from WSL or a remote machine tells you to use the host's IP and set the bind address to 0.0.0.0, which confirms the default is already permissive.

Authentication is a bearer token, described as mandatory and auto-generated on first run, required on every request. You can change IP, port and token from the Plugins menu, and saving restarts the server. That restart-on-save behaviour is worth knowing before you edit settings mid-session: the README says the server auto-restarts, not that the debug session survives it.

Tool surface is large. The feature list claims 84 MCP tools and 22 event callbacks, while the Tools section header says 72 tools and the tables that follow are shorter still. Treat the exact count as unverified and check the tool list your client reports after connecting. The categories are consistent across the README: state and loading, memory and disassembly, stepping, breakpoints including hardware and conditional, breakpoint management, and event long-polling through WaitForEvent and WaitForPause.

Installing the plugin and making a first Claude call

There is no package manager step. The README says to download the latest release or build from source, then copy the contents of dist/ into your x64dbg root folder. That deploys both the x32 and x64 plugins in one go. Launch x64dbg afterwards and the server starts automatically.

The plugin loads at startup. On first run it generates a bearer token, which you retrieve from the config dialog under the Plugins menu. The next step is the client config. The README gives this JSON for Streamable HTTP, which is the recommended transport:

{
  "mcpServers": {
    "x64dbg": {
      "type": "http",
      "url": "http://localhost:9094/",
      "headers": {
        "Authorization": "Bearer YOUR_TOKEN_HERE"
      }
    }
  }
}

Replace the placeholder with the token from the dialog. Legacy clients use type sse and the URL http://localhost:9094/sse with the same header. If the client connects, the README's example session shows what a working exchange looks like: you ask the assistant to load calc.exe and break at the entry point, and it calls LoadBinary, SetBreakpoint, run and WaitForPause in sequence. The reply reports the breakpoint address. From there, GetAllRegisters returns register values, ReadMemory returns a hex dump, and StepOver combined with GetCallStack walks the code.

One practical detail from the README: if you connect from WSL or another machine, use the host's IP address and set the bind address to 0.0.0.0 in the config dialog.

Where the design costs you: tokens, ports and no headless mode

The bearer token is mandatory, which is the right default for a listener on 0.0.0.0, but it is also the first thing that breaks a setup. The token is generated on first run and stored by the plugin; the README does not document a rotation procedure beyond changing it in the config dialog, and it does not discuss what happens to connected clients when the server restarts on save. Expect to re-copy the token into your client config after any change.

Port collisions are the second constraint. 9094 and 9095 are fixed defaults. The README documents changing them in the config dialog, which is fine, but every client config that hardcodes localhost:9094 has to change with them. There is no documented service discovery or environment variable override for the port.

Third, and most consequential: everything depends on a running x64dbg with a loaded target. There is no documented way to start the plugin outside the debugger, and no documented batch or CI mode. If your pipeline needs to debug a sample without a desktop session, this is the wrong tool, and the README offers no workaround. The same applies to 32-bit work: the x32 plugin listens on a different port, so a client configured for 9094 will not see an x32dbg session.

Finally, the tool inventory is inconsistent in the README itself. The Features list says 84 tools, the Tools heading says 72, and the tables shown are shorter than either. That is a documentation defect, not a runtime bug, but it means you cannot plan an automation around a count. Enumerate the tools from your connected client instead.

How it compares with a disassembler-side MCP server

The obvious alternative for people searching this space is an MCP server for Ghidra, which appears in the related searches around this project. The difference is the analysis model, not the protocol. A Ghidra-side server exposes a decompiler and a database of functions, so an agent reasons over reconstructed C and cross-references without running the binary. x64dbg-MCP Server exposes a live process: registers, memory, breakpoints, stepping, threads, call stacks, hardware breakpoints and tracing.

That split matters for what you can answer. Dynamic questions such as what value lands in a register after a specific API call, or which branch a packed sample takes at runtime, need a debugger. Static questions such as what a function does across a large binary are cheaper in a decompiler, and running the sample to find out may be impossible or unwise. The two are complementary, and nothing in this README suggests the project tries to be a decompiler.

The practical difference for adoption is operational. A Ghidra MCP setup typically runs as a separate process against a project file, which fits scripted pipelines. This plugin only exists inside x64dbg, which fits interactive analysis with an assistant watching alongside you. Choose based on whether your bottleneck is understanding code or observing execution.

Maintenance, licensing and what upgrading looks like

The repository is not archived, and the last push was on 2026-09-02, the same day as the v1.3 release. v1.2 and v1.1 both landed on 2026-08-27, so the release cadence in that window was rapid. The README does not document a changelog, a migration guide or a compatibility matrix between plugin versions and x64dbg versions, so upgrading means replacing the files in dist/ and reconnecting your client. The token is generated on first run; whether it survives a file replacement is not stated in the README, so verify it after any upgrade.

The licence is MIT, which is permissive and imposes no copyleft obligation on your own tooling. That is a statement about the licence text, not legal advice; if you redistribute the plugin inside a commercial product, read the LICENSE file in the repository root yourself.

Upgrade cost is dominated by the missing changelog rather than by the build. The project is written in Zig and ships a single binary with no runtime dependency, which the README presents as the reason there is nothing to install beyond copying files. The flip side is that there is no version negotiation documented between client and plugin, so a tool rename between releases would surface as a failed call in your client rather than a clear error. Pin a release you have verified, and re-check the tool list after each upgrade.

Editorial conclusion

Adopt it if you already debug in x64dbg and want an MCP client such as Claude to drive breakpoints, memory reads and stepping through the same session you watch on screen. Skip it if you need headless or CI debugging, since the plugin only runs inside a launched x64dbg instance, and skip it if your workflow is static analysis, where a disassembler-side MCP server fits better. Before you commit, verify three things on your own machine: that the auto-generated token in the config dialog works from your client, that the port you need is free, and that the tools you rely on are present in the release you downloaded, because the README's tool count does not match its tool tables.

Frequently asked questions

Official sources

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