x64dbg-mcp-server

What It Does

x64dbg-mcp-server is a native Model Context Protocol plugin for the x64dbg Windows debugger, written in Zig (5,865 lines across 7 source files, zero external dependencies). The plugin loads into x64dbg on startup, starts an HTTP server on a background thread (default 0.0.0.0:9094 for x64, 9095 for x32), and exposes the debugger to any MCP client over Streamable HTTP and SSE using JSON-RPC 2.0 with the 2024-11-05 protocol revision. The source registry defines 80 tools covering the full debugging workflow: breakpoints (software, hardware, memory, conditional, exception), stepping and tracing, memory read/write/allocate, registers, call stacks, threads, symbols and imports, PE analysis, packed-binary OEP detection, module dumping, and arbitrary debugger command execution. Twenty-two event callbacks push debugger events (breakpoints, exceptions, DLL loads, thread create and exit) to SSE clients in real time or queue them for HTTP clients that long-poll. The audience is reverse engineers and malware analysts on Windows who want an AI agent to drive x64dbg: load a binary, break at the entry point, step, read memory, unpack, and dump. The repo is two days old at test time (created 2026-08-22, 16 commits, one author), MIT licensed, and at 1,079 stars and 107 forks it is the fastest-rising fresh MCP server the GearScope pipeline scanner has tracked, the flagship so far of a forming RE live-debugging vertical alongside ghidra-mcp and headless IDA skills.

The Good

The tool surface is the deepest live-debugger control surface GearScope has tested. The 80-tool registry is a typed array of ToolDef structs, each with name, description, schema function, handler, and two flags (debug_only, read_only; 69 tools require an active session, 36 are read-only). Coverage spans the workflows a working analyst needs: SetHardwareBreakpoint with DR0-DR3 slot awareness, SetConditionalBreakpoint with expression conditions, TraceInto and TraceOver with per-step disassembly capture, FindPattern with wildcard bytes, DetectOEP for packed executables, DumpMemory and DumpModule for extraction, GetPEB and GetSEHChain for internals. The 22 event callbacks claimed in the README are exactly the 22 CB_ registrations in main.zig, verified by grep. Both transports are real: SSE clients get push notifications as JSON-RPC notifications/message frames, and HTTP clients get WaitForEvent long-polling plus a state line and queued event lines appended to every tool response, which is a thoughtful answer to the stale-state problem inherent in debugging over a request/response protocol.

The bundled SKILL.md is excellent agent discipline, the best part of the repo. The 285-line workflow guide teaches rules that map directly onto real failure modes: call GetDebugState before every action because between calls breakpoints can hit and the user can touch the GUI, never disassemble while the target is RUNNING, resolve symbols with EvalExpression before setting breakpoints, watch for events with WaitForEvent while the user interacts with the debugger GUI. It includes seven worked workflows (load and analyze, break and run, step, hook an API, trace, unpack, patch), a common-mistakes table with fixes, and a plain-language rule that the agent must name concrete addresses and modules instead of saying "the current function." An agent that follows this guide behaves like a careful analyst rather than a script firing blind requests.

Security was fixed fast, and the fixes are verifiably in the shipped binary. The v1.0-era server bound 0.0.0.0 with no authentication, which for a server that can read and write process memory is remote code execution by design; commit e1daba0 ("Add Bearer token authentication to prevent RCE on 0.0.0.0") and 1aad0f88 landed within roughly 26 hours, making the token mandatory on every request. The token is generated with SystemFunction036 (RtlGenRandom, the Windows CSPRNG), rotatable from the config dialog. The shipped .dp64 binary contains the Bearer comparison, the 401 Unauthorized response, and the error body, all confirmed by strings analysis. The README also carries an unusually honest disclaimer: the tool grants full process control over a network interface, the HTTP transport is unencrypted, and the server should not be exposed to untrusted networks.

The engineering substrate is clean and the release artifacts are healthy. One build.zig cross-compiles the single codebase to both targets (x86-windows-gnu and x86_64-windows-gnu), the x64dbg SDK is resolved at runtime from x64bridge.dll and x64dbg.dll rather than linked, and there is no runtime dependency at all. The v1.1 zip contains exactly two DLLs (999,936-byte PE32 .dp32 and 977,408-byte PE32+ .dp64), both exporting the complete plugin contract (pluginit, plugsetup, plugstop), so the drop-in install path is real.

The Bad

The shipped v1.1 binary is missing 9 of the 80 documented tools, including the release's headline feature. A strings census of the shipped .dp64 found only 71 of the 80 source tool names embedded. Missing: WaitForEvent, SetMemoryBreakpoint, SetExceptionBreakpoint, DeleteExceptionBreakpoint, AnalyzeCode, TraceOver, SetBreakpointCommand, SetBreakpointFastResume, and SaveDatabase. The binary contains the [state] response lines but zero [event: strings, which places it at commit 9f3c694 (real-time state awareness), the commit before the v1.1 tag. The v1.1 tag itself (eb63792) does contain all 80 tools. In other words, the author tagged v1.1 and uploaded a binary built from the pre-v1.1 tree. Practical consequence: the README and SKILL.md instruct HTTP clients to call WaitForEvent, and on the binary users actually download that tool does not exist. With no CI and hand-built releases, nothing catches this class of error, and with only 25 v1.1 downloads at test time (against 282 for v1.0) almost nobody has hit it yet.

No stable Zig release can build the current source. The README says "Requires Zig 0.16-dev or later," and that is the problem: the code was written against a 0.16.0-dev snapshot, and Zig 0.16.0 stable subsequently changed os.windows.Bool from a plain c_int to a distinct type, breaking 24 call sites in bridge.zig (errors like "cannot @bitCast from 'os.windows.Bool(c_int)'" and "incompatible types: 'os.windows.Bool(c_int)' and 'comptime_int'"; 51 error lines total, build dies in 8 seconds). Zig 0.15.2 fails with 24 undefined host-library symbols (_abort, _arc4random_buf, _clock_gettime) leaking into the windows-gnu link, and 0.14.1 fails with 17 of the same class, despite build.zig.zon declaring minimum_zig_version 0.14.0, which is simply false. Zig master is already 0.17.0-dev, so the dev snapshot that compiled this code is no longer the featured download. Building this repo today requires archaeology through Zig's archived dev snapshots, and the README's "Builds on Windows, WSL, Linux, or macOS" claim did not hold on this macOS host for any of the three stable toolchains tested.

Four different tool counts appear in the docs, and none of the marketing numbers is right. The README Features bullet claims "84 MCP Tools," the README Tools section header says "72 MCP tools," the SKILL.md says "All 84 Tools Reference," and the v1.1 commit message says 84. The source registry holds exactly 80, the README and SKILL.md reference tables each list exactly those 80 with perfect set equality to the source (this part is impeccable), and the shipped binary holds 71. A reader cannot determine from the docs which number to believe, and the two reference tables being correct makes the three headline numbers look like nobody recounted after the final commit.

The SKILL.md cannot be installed as an agent skill. It has no YAML frontmatter: the first line is a markdown heading, not ---, so the required name and description fields are absent. Running the standard installer (npx skills add duty1g/x64dbg-mcp-server) prints "Skipped SKILL.md, missing required frontmatter field(s): name, description" and "No valid skills found," then exits 0 having installed nothing. The excellent 285-line agent guide therefore has no distribution channel: every user must hand-copy it into their client, and the repo is invisible to skills.sh-style registries that index SKILL.md frontmatter.

The server is multi-threaded with zero synchronization, compiled single-threaded. The plugin spawns the server thread and one client thread per connection with raw CreateThread calls, while x64dbg debugger callbacks run logAndPush, which calls notifyEvent, which writes the pending-events ring buffer (pending_head, pending_count) and iterates the SSE client array, all state that HTTP client threads concurrently read and drain. There is not one atomic, mutex, critical section, or interlocked operation anywhere in the source tree, and build.zig sets single_threaded = true on both modules, which tells the compiler not to emit atomic operations at all. This is a static-analysis finding rather than a reproduced crash, and torn word-sized writes are unlikely on x86, but lost updates on the ring-buffer counters under concurrent load are plausible, which would drop or duplicate queued events. Separately, the default bind address is 0.0.0.0 on all interfaces with plaintext HTTP; the mandatory token mitigates this, and the README discloses it, but a localhost default would remove the risk class entirely.

Smoke Test Results

Host-based runs on macOS 26.5.2 aarch64 (the sbx sandbox daemon was not authenticated this session, so the scripts ran directly on the host with logs captured to the standard sandbox paths). The server itself is a Windows-only plugin DLL, so a live start and a live MCP handshake are impossible on this host; the runs below verify everything verifiable short of that: the install path, the plugin contract, the build path, and the tool contract across source, docs, and shipped binary. Logs ship verbatim.

Install

$ git clone --depth 16 https://github.com/duty1g/x64dbg-mcp-server.git /tmp/x64dbg-mcp-smoke
✅ clone succeeds; 16 commits, 7 core files (LICENSE, README.md, SKILL.md, build.zig, build.zig.zon, src/ tree), repo 1.8 MB

$ ls /tmp/x64dbg-mcp-smoke/src/core /tmp/x64dbg-mcp-smoke/src/mcp
✅ all 7 documented source files present (main.zig, core/bridge.zig, core/config.zig, core/mcp_server.zig, mcp/json.zig, mcp/tools.zig, resources/icons.zig)

$ head -1 /tmp/x64dbg-mcp-smoke/SKILL.md
❌ prints a markdown heading as the first line; there is no YAML frontmatter block, so name and description are missing

$ npx -y skills add duty1g/x64dbg-mcp-server
❌ reports "missing required frontmatter field(s): name, description", then "No valid skills found.", and exits 0 having installed nothing

$ curl -sL -o x64dbg-MCP-Server.zip https://github.com/duty1g/x64dbg-mcp-server/releases/download/v1.1/x64dbg-MCP-Server.zip
✅ 754,898 bytes downloaded

$ unzip -l x64dbg-MCP-Server.zip
✅ exactly x32/plugins/x64dbg-MCP-Server.dp32 and x64/plugins/x64dbg-MCP-Server.dp64

$ file x32/plugins/*.dp32 x64/plugins/*.dp64
✅ PE32 executable (DLL) Intel 80386 (999,936 bytes) and PE32+ executable (DLL) x86-64 (977,408 bytes), both for MS Windows

Pass rate: 5 of 7. The release-zip install path is clean and healthy; the agent-skill install path is dead because of the missing frontmatter.

Full install log →

Server starts

$ objdump -p x64/plugins/x64dbg-MCP-Server.dp64 | grep plug
✅ exports pluginit, plugsetup, plugstop (full x64dbg plugin contract; .dp32 exports them too)

$ (load the DLL and hit http://localhost:9094/)
❌ impossible on this host: the server lives inside x64dbg on Windows; no macOS/Linux load path exists

$ zig-0.16.0 build -Doptimize=ReleaseSafe --prefix dist # README build command, current stable
❌ 51 error lines, 24 errors: cannot @bitCast from 'os.windows.Bool(c_int)' in bridge.zig; no output artifacts

$ zig-0.15.2 build -Doptimize=ReleaseSafe --prefix dist
❌ 24 error lines: undefined symbols _abort, _arc4random_buf, _clock_gettime (host libc leaking into windows-gnu link)

$ zig-0.14.1 build -Doptimize=ReleaseSafe --prefix dist # the floor build.zig.zon declares
❌ 17 error lines, same undefined-symbol class

Pass rate: 1 of 5. The plugin export contract verifies, but the server cannot start off-Windows and the documented build path fails on every stable Zig currently downloadable.

Full server-starts log →

Tools respond

The live handshake (initialize, tools/list, tools/call) is the one thing this host cannot run, so this section verifies the tool contract statically: source registry versus README versus SKILL.md versus the shipped binary, plus the protocol and auth strings embedded in the binary users download.

$ python3 sandbox/skills/x64dbg-mcp-server/tools-census.py /tmp/x64dbg-mcp-smoke <shipped .dp64>
✅ counts: SOURCE tool count 80, README tool table count 80, SKILL.md tool table count 80

$ grep "NOT in" /tmp/x64dbg-census-out.txt | grep -vc ": none"
✅ 0: the three sets are identical, no duplicates in the source array

$ grep -c "84 MCP Tools" README.md
❌ 1 hit: the Features bullet claims 84 tools; the source registry holds 80

$ grep -n "^72 MCP tools" README.md
❌ 1 hit: the Tools section header claims 72; stale count

$ grep -n "All 84 Tools" SKILL.md
❌ 1 hit: the SKILL.md reference header claims 84; stale count

$ strings x64/plugins/x64dbg-MCP-Server.dp64 | grep -c "^WaitForEvent$"
❌ 0: the documented long-polling tool is absent from the shipped v1.1 binary

$ strings x64/plugins/x64dbg-MCP-Server.dp64 | grep -cE "^(GetDebugState|SetBreakpoint)$"
✅ 2: sample tools from the 71 that are embedded (71 of 80 total)

$ strings x64/plugins/x64dbg-MCP-Server.dp64 | grep -c "^2024-11-05$"
✅ 1: MCP protocolVersion pinned to 2024-11-05

$ strings x64/plugins/x64dbg-MCP-Server.dp64 | grep -c "401 Unauthorized"
✅ 1: unauthorized responses present

$ strings x64/plugins/x64dbg-MCP-Server.dp64 | grep -c "^Bearer $"
✅ 1: the Authorization header check is compiled in

$ strings x64/plugins/x64dbg-MCP-Server.dp64 | grep -m1 "0.0.0.0"
✅ default bind-all address embedded, matching README ports 9094/9095

$ grep '.version = ' build.zig.zon
❌ declares 1.0.0 while the latest release tag is v1.1 (manifest drift)

$ git show v1.1:src/mcp/tools.zig | grep -c '.name = "'
✅ 84 raw matches at the tag (80 tools + 4 register-name literals): the tag has the full registry; the zip does not

$ python3 scripts/skill-review/mcp-stdio-client.py ./x64dbg-MCP-Server.dp64 stdio
❌ not runnable: the server speaks HTTP inside a Windows plugin DLL, not stdio, and there is no Windows host

Pass rate: 8 of 14. The contract checks that could run all behaved as the source says they should. The failures are the live handshake (environmental), the three stale doc counts, the zon version drift, and the missing-tools-in-binary finding, which is the one real product defect this review found.

Full tools-respond log →

What the runs tell you

The repo, docs, and release artifacts are structurally healthy and the 80-tool registry in source matches its reference tables exactly, but the binary users download today predates the v1.1 tag and ships 71 tools, the documented build path fails on every stable Zig, and the agent guide cannot be installed through the standard skills CLI. Until the author rebuilds and re-uploads v1.1 (or cuts v1.2) and adds frontmatter to SKILL.md, install the zip and treat the docs as describing one version ahead of the binary.

Setup Walkthrough

1. Download x64dbg-MCP-Server.zip from the releases page (754,898 bytes at v1.1).
2. Unzip the contents into your x64dbg root folder; the dist tree mirrors x64dbg's layout, so x32/plugins and x64/plugins land in place.
3. Launch x64dbg. The plugin auto-starts: x64 listens on 0.0.0.0:9094, x32 on 9095, and mcp_config.json is written next to the executable.
4. Open Plugins, then x64dbg-MCP Server, then Configure MCP Server to see the auto-generated Bearer token (Copy) and optionally rotate it (Generate) or switch the bind to 127.0.0.1. The server restarts on save.
5. Add the server to your MCP client as type http, url http://localhost:9094/, with an Authorization: Bearer header carrying your token. Legacy clients can use the SSE endpoint at /sse.
6. Hand-copy SKILL.md into your agent's instructions if you want the workflow discipline it teaches; the skills CLI cannot install it (no frontmatter).
7. Building from source instead: the README command (zig build -Doptimize=ReleaseSafe --prefix dist) fails on Zig 0.14.1, 0.15.2, and 0.16.0 stable as documented above. You need the specific 0.16.0-dev snapshot the author used, which predates the os.windows.Bool change.

Alternatives

1. bethington/ghidra-mcp: the adjacent node in the same vertical (3,435 stars at last scan). Static analysis, decompilation, and function-level queries in Ghidra rather than live process control. Choose it when you need source-level understanding rather than a live debugger; the two chain well in one agent session.
2. headless IDA skills (pipeline scan #179): drive IDA 9.4 headlessly for disassembly and decompiler work. Same static-versus-live split, heavier license footprint.
3. Moonriseandset/cachito-shikong-mcp: BLE-protocol reverse engineering MCP for a consumer device, evidence the agentic-RE niche is specializing. Only relevant if your target speaks that protocol, but it shows the one-debugger-one-server pattern this repo exemplifies.