x64dbg-MCP Server Gives an Agent 71 Debugger Tools and Ships Listening on 0.0.0.0

A native Zig plugin turns a Windows debugger into an agent-callable API. The engineering is sharp. The defaults deserve five minutes of your attention before you launch it.

Attach a debugger to a program and you have already won the argument about trust. You can read any byte the process owns, rewrite instructions in place, allocate memory inside it, and force it down paths its author never intended. That is the job. Reverse engineers accept the power because a human is holding it and a human is watching.

x64dbg-MCP Server hands that entire surface to a language model through 71 MCP tools, and it starts up on its own the moment x64dbg launches, listening on every network interface the machine has.

Both halves of that sentence are worth taking seriously. The tool works, and the way it had to be built tells you something uncomfortable about the state of MCP outside the hosted, well-funded parts of the ecosystem.

What it actually is

The project is a native plugin written in Zig, MIT licensed, by a developer who goes by duty1g. It compiles to a single .dp64 or .dp32 file that you drop into your x64dbg folder. No Python bridge, no .NET runtime, no separate process to babysit. One command, zig build -Doptimize=ReleaseSafe --prefix dist, produces both architectures, and it cross-compiles from Linux, macOS, or WSL to Windows targets.

That last detail is the part I respect most. Debugger plugins are usually a Visual Studio project with a decade of accumulated build lore. This one builds from a Mac.

The plugin loads into x64dbg at startup, resolves the debugger's API symbols at runtime from x64bridge.dll and x64dbg.dll, and spins up an HTTP server on a background thread. It lives inside x64dbg's own address space with direct access to the debugger API, so there is no polling loop and no IPC layer to go wrong.

The tool surface earns its number. I counted the README tables: 10 tools that work with no active debug session, 61 more that require one, which lands exactly on the advertised 71. They cover disassembly, stepping, hardware and conditional breakpoints, register reads and writes, thread control, the memory map, pattern scanning with wildcards, xref discovery, PE section analysis, original entry point detection for packed binaries, PEB and SEH inspection, and instruction tracing. Twenty-two event callbacks push debugger events back out: exceptions, breakpoint hits, DLL loads, attach and detach.

There is one design touch I have not seen elsewhere. The initialize response carries an instructions string with ten numbered rules that teach the model how to drive a debugger: call GetDebugState first, remember that the target must be paused before you read memory, use WaitForPause after run instead of assuming execution stopped. The server ships its own operating manual to whatever model connects. More MCP servers should do that.

The part that needs five minutes

Read the source and you find the security model is real, and it is documented almost nowhere.

Every request goes through an authorization check before routing. The server looks for an Authorization: Bearer header and compares it against a token generated on first run from SystemFunction036, the Windows CSPRNG, sixteen random bytes rendered as thirty-two hex characters. Anything that does not match gets a 401. If no token is configured at all, every request gets a 401. That is fail-closed, and it is the right default. Credit where it is due.

Now the friction. The token is written to mcp_config.json sitting next to your x64dbg executable, in plaintext, and it never expires. The README never mentions it. The client configuration the README tells you to paste is a bare URL with no headers, which means the documented setup returns 401 on every call and you go find the config dialog by trial and error. The dialog has a Copy button for the token, which is the only place the thing surfaces.

Then the defaults. In config.zig the initial bind address is 0.0.0.0, the port is 9094 for x64 and 9095 for x32, and auto_start is true. Install the plugin, launch x64dbg, and you are serving on every interface the box has without touching a setting. The config dialog offers 127.0.0.1 and the README explains what it is for, but you have to know to go looking.

Between an attacker on your network and AttachProcess, ExecuteDebuggerCommand, WriteMemToAddress, and DumpModule there is one static hex string, sent in cleartext over plain HTTP on every single request. On a reverse engineering box, which by definition has a debugger attached to something hostile.

The CORS policy is Access-Control-Allow-Origin: * with Authorization in the allowed headers and no Origin validation anywhere. The token still stops a drive-by page from doing anything, so this is not an open door. It does mean the token is the only wall, and it is a wall that leaks every time you use it on an untrusted network.

The reason this happened

Look at line 15 of mcp_server.zig:

const PROTOCOL_VERSION = "2024-11-05";

That is an MCP revision from before the protocol had an authorization story worth the name. No issuer validation, no Client ID Metadata Documents, no Enterprise-Managed Authorization, none of the hardening that landed in the 2026-07-28 release. A developer targeting that revision who wants any access control has exactly one option: write it themselves. So duty1g did, and produced a reasonable static bearer scheme, which is roughly what everyone writes when they have to write it themselves.

Two days after this repo hit the trending boards, MCP's lead maintainers published a roadmap naming the problem out loud. MCP authorization today "is built around a person approving access in a browser," they write, and the fix they are steering toward is proof of possession, Workload Identity Federation, and token exchange, "built on existing standards rather than pasted API keys and long-lived tokens."

A plaintext hex string in a JSON file next to the executable is a pasted API key. It is a long-lived token. The roadmap is describing this repo without having seen it.

That is what makes this project worth writing about rather than just installing. It is a competent, current, genuinely useful piece of tooling that had to hand-roll its own auth because the protocol version it targets offers none, and it is exactly the artifact the protocol's own maintainers point at when they explain why they are prioritizing agent identity.

Put this into practice

If you want to try it, and it is worth trying, do these things in this order and it costs you about five minutes.

Set up the isolation first. This belongs in the analysis VM you already use for malware work, not on your daily machine. Everything below assumes that.

Launch x64dbg once so the plugin generates its config, then go to Plugins, x64dbg-MCP Server, Configure MCP Server. Change the IP field from 0.0.0.0 to 127.0.0.1 and save. The server restarts on save, so this takes effect immediately.

While that dialog is open, hit Copy on the token and put it in your MCP client config, which the README does not show you how to do:

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

Uncheck auto-start unless you want a listener every time you open the debugger. Turning it on deliberately when you want an agent session is a better habit than leaving it armed.

If you genuinely need to reach it from WSL or another host, forward the port over SSH instead of binding to 0.0.0.0. You get the same access without putting a cleartext bearer token on the wire.

Then do the thing the tool is actually for. Load a packed sample, ask the agent to run DetectOEP, follow it with AnalyzeModule and GetStrings, and watch how it reasons across the results. The value here is not that it does anything a skilled analyst cannot. It is that the tedious middle of an unpacking session, the run-break-inspect-repeat loop, is exactly the shape of work an agent is good at.

Honest limitations

I read the source rather than running it. I have not built the plugin, attached it to a live target, or measured how well a model actually drives 71 tools without losing the thread. The security claims here come from mcp_server.zig and config.zig on main, which is solid ground for what the code does and no ground at all for how it behaves in a real session.

The repo also moves fast enough that details go stale. Earlier reporting on this project noted the README contradicting itself on the tool count, 84 in one place and 72 in another. That is fixed now, and both the feature list and my own count of the tables say 71. Check the source rather than any article, including this one.

The token design is better than the defaults make it look, and I do not want the criticism to land as an accusation. Fail-closed on a missing token, CSPRNG-generated, persisted across restarts, regenerable from the dialog: that is more care than most one-developer MCP servers show. The gap is documentation and a bind address, not competence.

There is a deeper limit nobody can engineer around. An agent driving a debugger is an agent reading attacker-controlled bytes and deciding what to do next. Strings pulled out of a hostile binary land in the model's context. If you have been following prompt injection at all, you already see the shape of that. Nothing in this repo makes it worse than any other agentic RE setup, and nothing in this repo makes it better either.

What to take from it

Install it in a VM, flip the bind address, and spend an hour seeing whether agentic reverse engineering is real for the work you do. My read is that it is closer than the skeptics think and further than the demos suggest.

Then look at what it took to build. One developer, a debugger API, and a protocol revision that left authorization as an exercise for the reader. The next hundred MCP servers in specialized domains will be built the same way by people with the same constraint, and most of them will hand-roll something less careful than this one did. That is the story worth watching, and it is why the roadmap's agent identity work matters more than any single feature on it.

Sources: duty1g/x64dbg-mcp-server README and source (src/core/mcp_server.zig, src/core/config.zig) on main, read August 24, 2026; The New MCP Roadmap (August 22, 2026); MCP 2026-07-28 specification changelog; x64dbg.