Skip to main content
Glama
x64dbg MCP Server

x64dbg MCP Server

by ouonet

x64dbg MCP Server

A production-level Model Context Protocol server that exposes x64dbg reverse-engineering and debugging capabilities to AI assistants over STDIO or Streamable HTTP.

It is designed for practical debugger automation, not just toy examples:

  • Auto-detects PE architecture and launches x32dbg or x64dbg as needed

  • Supports both load_executable and attach_to_process

  • Exposes debugging, memory, analysis, and security triage tools through MCP

  • Uses a lightweight bridge plugin and talks to x64bridge.dll directly via ctypes

  • Does not depend on x64dbgpy

Quick Start

npm install -g x64dbg-mcp
x64dbg-mcp setup
x64dbg-mcp doctor

After that, choose one transport:

  • STDIO: let your MCP host launch x64dbg-mcp directly

  • Streamable HTTP: start a long-running server with:

x64dbg-mcp --transport streamable-http --host localhost --port 3000

The HTTP endpoint is fixed at http://localhost:3000/mcp.

stdio and streamable-http are the supported startup transports. The SDK still ships a standalone SSE server transport, but it is deprecated and this project does not expose it as a separate mode.

Related MCP server: Binary MCP Server

Requirements

  • Windows only, because x64dbg is Windows-only

  • Node.js 20+

  • Python 3.10+

  • CMake 3.15+ plus MSVC or MinGW only if you need to build the C loader from source

npm install downloads x64dbg automatically if it is not already available. The iced_x86 Python package is also installed automatically into detected Python environments; if that installation fails, the bridge falls back to x64dbg's own disassembly APIs.

Installation

Global npm install

npm install -g x64dbg-mcp

The global install path is the simplest one. Its postinstall step handles the usual setup work:

Step

What happens

x64dbg

Downloads the latest snapshot if not found locally

Plugin files

Deploys the loader and Python bridge files into the x64dbg plugins directories

Bridge auth

Generates BRIDGE_AUTH_TOKEN and writes x64dbg_mcp_bridge.token

Python

Detects Python install paths and records PYTHON_HOME_X64 / PYTHON_HOME_X86

iced_x86

Installs it into detected Python environments if needed

.env

Creates a config file with detected values and defaults

Before continuing, review the configuration values in the next section if your x64dbg install path, Python install path, or HTTP port should differ from the detected defaults.

Then run:

x64dbg-mcp setup
x64dbg-mcp doctor
x64dbg-mcp

If you need to rebuild and redeploy the loader manually, use:

x64dbg-mcp install-plugin

Source checkout

Use this path if you are developing on the project itself:

git clone https://github.com/ouonet/x64dbg-mcp.git
cd x64dbg-mcp
npm install
npm run build

Then review the configuration section below, especially if X64DBG_PATH, Python paths, or the default HTTP port need to change.

npm run setup
npm run install-plugin
npm run doctor
npm start

To run HTTP mode from a source checkout:

node .\dist\server.js --transport streamable-http --host localhost --port 3000

If you want the x64dbg-mcp command in a source checkout too, run npm link after npm run build.

If x64dbg already exists in a non-default location, set X64DBG_PATH in .env before npm run install-plugin.

Manual plugin installation

Most users should not need this. Use it only if you want to build and copy the loader manually instead of running install-plugin.

cd plugin\loader

# 64-bit
cmake -B build64 -A x64
cmake --build build64 --config Release
$p64 = "C:\x64dbg\release\x64\plugins"
Copy-Item build64\Release\x64dbg_mcp_loader.dp64 $p64
Copy-Item ..\x64dbg_mcp_bridge.py                $p64
Copy-Item ..\x64dbg_bridge_sdk.py                $p64

# 32-bit
cmake -B build32 -A Win32 -DBUILD_32BIT=ON
cmake --build build32 --config Release
$p32 = "C:\x64dbg\release\x32\plugins"
Copy-Item build32\Release\x64dbg_mcp_loader.dp32 $p32
Copy-Item ..\x64dbg_mcp_bridge.py                $p32
Copy-Item ..\x64dbg_bridge_sdk.py                $p32

npm run install-plugin performs the same work for both architectures by default. Pass -No32 if you want to skip the 32-bit build.

Configuration

npm install creates .env automatically. Edit that file directly, or run setup again if you want the interactive flow.

# x64dbg path (auto-detected)
X64DBG_PATH=C:\x64dbg

# Python install directories used by the C loader
PYTHON_HOME_X64=C:\Python314
PYTHON_HOME_X86=C:\Python312-32

# Bridge
BRIDGE_HOST=127.0.0.1
BRIDGE_PORT=27042
BRIDGE_AUTH_TOKEN=<auto-generated>

# MCP transport defaults
MCP_TRANSPORT=stdio
MCP_HTTP_HOST=127.0.0.1
MCP_HTTP_PORT=3000

# Logging / limits
LOG_LEVEL=info
MAX_SESSIONS=1
SESSION_TIMEOUT_MS=3600000

Variable

Default

Description

X64DBG_PATH

auto-detected

x64dbg installation directory

PYTHON_HOME_X64

auto-detected

Preferred Python 64-bit install directory

PYTHON_HOME_X86

auto-detected

Preferred Python 32-bit install directory

BRIDGE_HOST

127.0.0.1

TCP host for the local bridge

BRIDGE_PORT

27042

TCP port for the local bridge

BRIDGE_AUTH_TOKEN

auto-generated

Shared secret for MCP to bridge requests

MCP_TRANSPORT

stdio

Default startup transport: stdio or streamable-http

MCP_HTTP_HOST

127.0.0.1

Default HTTP bind host

MCP_HTTP_PORT

3000

Default HTTP listen port

LOG_LEVEL

info

error, warn, info, or debug

MAX_SESSIONS

1

Active session limit for the current bridge architecture

SESSION_TIMEOUT_MS

3600000

Idle session timeout in milliseconds

If you manually start x64dbg outside the MCP flow, keep the deployed x64dbg_mcp_bridge.token file in the plugins directory so the bridge enforces the same token as the MCP server.

Use With Your MCP Host

Note: You do not need to pre-launch x64dbg manually. The MCP server auto-launches the correct debugger when you call load_executable or attach_to_process.

STDIO host configuration

Use STDIO when your MCP host can spawn a local process.

Claude Desktop

If you installed the package globally:

{
  "mcpServers": {
    "x64dbg-mcp": {
      "command": "x64dbg-mcp"
    }
  }
}

If you are using a source checkout instead:

{
  "mcpServers": {
    "x64dbg-mcp": {
      "command": "node",
      "args": ["C:\\path\\to\\x64dbg-mcp\\dist\\server.js"]
    }
  }
}

Windsurf / Cascade

{
  "mcpServers": {
    "x64dbg-mcp": {
      "command": "node",
      "args": ["C:\\path\\to\\x64dbg-mcp\\dist\\server.js"],
      "env": { "BRIDGE_PORT": "27042" }
    }
  }
}

Streamable HTTP

Use Streamable HTTP when you want to start x64dbg-mcp once and let an AI tool connect to it through a fixed local URL.

Start the server first.

If you installed the package globally:

x64dbg-mcp --transport streamable-http --host localhost --port 3000

If you are running from a source checkout:

node .\dist\server.js --transport streamable-http --host localhost --port 3000

Then connect your AI tool to this MCP endpoint:

http://localhost:3000/mcp

Below are direct configuration examples for common AI tools.

Claude Code

Create a .mcp.json file in the project root:

{
  "mcpServers": {
    "x64dbg-mcp": {
      "type": "http",
      "url": "http://localhost:3000/mcp"
    }
  }
}

Or add the same server to Claude Code with its CLI:

claude mcp add --transport http x64dbg-mcp http://localhost:3000/mcp

Windsurf / Cascade

Edit ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "x64dbg-mcp": {
      "serverUrl": "http://localhost:3000/mcp"
    }
  }
}

If you already have other MCP servers configured in that file, just add the x64dbg-mcp entry under mcpServers.

If your AI tool does not support remote HTTP MCP servers and only knows how to launch a local command, use the STDIO setup above instead.

CLI flags override MCP_TRANSPORT, MCP_HTTP_HOST, and MCP_HTTP_PORT from the environment. The legacy MCP_TRANSPORT=http alias is still accepted for compatibility.

Typical Prompts

These are good examples of the kinds of requests the MCP server is built to support:

  • "Load C:\samples\target.exe and analyze it for suspicious behavior"

  • "Attach to PID 1234 and inspect the current thread"

  • "Find the license check function"

  • "Generate a first-pass malware triage report"

Typical tool flows behind those prompts look like this:

Goal

Typical tools

Load and debug a binary

load_executable, get_status, continue_execution, wait_for_state, disassemble

Attach to a live process

attach_to_process, get_status, pause_execution, get_call_stack, get_registers, detach_session

Malware triage

generate_security_report, analyze_suspicious_apis, detect_anti_debug, find_strings

Reverse engineering

find_strings, get_cross_references, analyze_function, collect_bp_args

Capabilities

The server exposes 38 tools across four practical groups.

Group

Scope

Core debugging

load or attach, control execution, manage breakpoints, inspect session state

Memory and registers

read and write memory, inspect registers, switch threads, walk call stacks

Analysis

disassembly, function analysis, cross references, modules, imports, exports, strings, traces

Security triage

packing checks, suspicious APIs, anti-debug detection, section anomalies, consolidated reports

Representative tools include load_executable, attach_to_process, get_status, read_memory, disassemble, analyze_function, and generate_security_report.

Architecture

┌─────────────────┐  STDIO / HTTP     ┌──────────────────┐  TCP (JSON)  ┌──────────────┐
│  AI Assistant   │ ◄───────────────► │  MCP Server      │ ◄──────────► │  x64dbg      │
│  (Claude, etc.) │                   │  (Node.js / TS)  │  port 27042  │  + Bridge    │
└─────────────────┘                   └──────────────────┘              │    Plugin    │
                                                                        └──────────────┘

At a high level, the MCP server in src/ speaks STDIO or Streamable HTTP to an AI client, then forwards requests over a local TCP bridge to the plugin running inside x64dbg. The plugin side is a lightweight C loader plus Python bridge that translates those requests into x64dbg Bridge SDK calls.

Development And Testing

Development commands:

npm run ci
npm run ci -- --no-loader
npm run dev
npm run sync-plugin
npm run setup-x64dbg
npm run setup-x64dbg -- --force
npm run build
npm run lint
npm run clean

Testing commands:

npm test
python plugin/tests/test_bridge.py
npm run test:e2e
npm run test:http-smoke
npm run doctor

npm run dev automatically syncs Python files into the bundled x64dbg checkout before starting the server.

npm run inspector launches MCP Inspector. On first run it downloads @modelcontextprotocol/inspector via npx, so restricted environments may need HTTP_PROXY / HTTPS_PROXY or a global install.

Reusable verifier scripts live under test/e2e/. They require an explicit target:

  • TARGET_EXE=C:\path\to\sample.exe for load-based verification

  • TARGET_PID=1234 or TARGET_PROCESS_NAME=notepad for attach-based verification

Examples:

$env:TARGET_EXE = "C:\Windows\System32\notepad.exe"
node test/e2e/verify_breakpoint_chain.mjs

$env:TARGET_PROCESS_NAME = "notepad"
node test/e2e/verify_attach_chain.mjs

CI in .github/workflows/ci.yml runs TypeScript, Python, and loader-build jobs on every push. On tagged releases (v*), it also publishes the npm package with the prebuilt loader binaries included.

Project Structure

x64dbg-mcp/
├── src/
│   ├── server.ts              # Entry point and transport bootstrap
│   ├── cli.ts                 # CLI parsing for transport/host/port
│   ├── httpServer.ts          # Streamable HTTP server and MCP session handling
│   ├── mcpServer.ts           # Shared MCP server factory and tool registration
│   ├── bridge.ts              # TCP client for the x64dbg bridge
│   ├── launcher.ts            # PE detection and debugger startup
│   ├── session.ts             # Session lifecycle and garbage collection
│   ├── config.ts              # Env-backed configuration loading
│   ├── errors.ts              # Shared error helpers
│   ├── logger.ts              # Winston logger
│   ├── types.ts               # Shared TypeScript types
│   └── tools/
│       ├── debug.ts
│       ├── memory.ts
│       ├── analysis.ts
│       ├── security.ts
│       └── index.ts
├── plugin/
│   ├── x64dbg_mcp_bridge.py   # Python bridge running inside x64dbg
│   ├── x64dbg_bridge_sdk.py   # ctypes wrapper for x64bridge.dll
│   ├── loader/
│   │   ├── x64dbg_mcp_loader.c
│   │   ├── CMakeLists.txt
│   │   └── prebuilt/
│   ├── tests/
│   │   └── test_bridge.py
│   └── README.md
├── scripts/
│   ├── setup.mjs
│   ├── doctor.mjs
│   ├── install-plugin.mjs
│   ├── install-plugin.ps1
│   ├── postinstall.mjs
│   ├── prepack.mjs
│   ├── setup-x64dbg.mjs
│   ├── sync-plugin.mjs
│   ├── ci.mjs
│   └── manual/
├── test/
│   ├── basic.test.ts
│   └── e2e/
├── x64dbg/                    # Bundled x64dbg snapshot used in development/tests
├── package.json
├── .env.example
└── README.md

License

MIT

Community

For non-sensitive questions or usage issues, open a GitHub issue. For vulnerabilities, follow the private reporting process in SECURITY.md instead of opening a public issue.

Available Tools

39 tools
analyze_functionA

Analyse the function that contains the given address. Returns boundaries, size, call graph (callers + callees), and whether the function is a leaf.

Inputs: sessionId (required), address (required).

analyze_suspicious_apisA

Cross-reference the executable's import table against a database of Windows APIs commonly used by malware, grouped by category (process injection, network, crypto, anti-debug, etc.). Returns per-category findings and an overall risk level.

Inputs: sessionId (required), module, includeAll.

check_section_anomaliesA

Check PE sections for anomalies that may indicate packing, code injection, or tampering: writable+executable sections, unusual names, zero raw-size with non-zero virtual-size, high entropy.

Inputs: sessionId (required), module.

close_debuggerA

Kill the x64dbg or x32dbg process. Works even if the bridge is not connected. Use this to cleanly shut down the debugger before deploying updated plugins or when you need to restart the debugger.

Inputs: force.

collect_bp_argsA

Continue execution in a loop, collecting a memory expression at each breakpoint hit. Use this to trace repeated calls (e.g. AddMoudle, GetClassObject). The default expr 'ptr_utf16@[esp+4]' reads a wchar_t* arg from the x86 stack.

Inputs: sessionId (required), expr, maxHits, timeoutSec.

continue_executionA

Resume execution of a paused debuggee. Runs until the next breakpoint, exception, or program exit. REQUIRES: session state must be 'paused' (check with get_status). Returns stopReason ('breakpoint', 'paused', or 'exited') and the address where execution stopped. If stopReason is 'exited', the process has terminated.

Inputs: sessionId (required).

detect_anti_debugB

Scan the loaded executable for common anti-debugging techniques: API checks (IsDebuggerPresent, NtQueryInformationProcess), timing checks, PEB flags, int 2d / int 3, TLS callbacks, etc.

Inputs: sessionId (required), module.

detect_packingA

Analyse the loaded executable for signs of packing or obfuscation. Checks section entropy, section name anomalies, import table size, entry-point location, and known packer signatures. Returns a confidence score and list of indicators.

Inputs: sessionId (required), module.

disassembleA

Disassemble instructions starting at a given address in the loaded module. Returns address, raw bytes, mnemonic, operands, and metadata (is_call, is_jump, reference target) for each instruction. Safe to call while paused. Address may be a hex value ('0x401000') or a symbol name ('main', 'kernel32.CreateFileW'). Tip: after load_executable with breakOnEntry=true, disassemble the entry point returned in the load result to see where execution begins.

Inputs: sessionId (required), address (required), count.

execute_commandA

Execute a raw x64dbg command string. Use this for advanced operations not covered by other tools. Returns the command output.

Inputs: sessionId (required), command (required).

find_stringsB

Search for ASCII and Unicode strings in the debuggee's memory. Optionally filter by content substring or module.

Inputs: sessionId (required), module, filter, minLength, +1 more.

generate_security_reportA

Run all security analysis tools and produce a consolidated report: packing detection, suspicious API analysis, anti-debug detection, and section anomaly checks. Useful as a first-pass triage.

Inputs: sessionId (required), module.

get_call_stackA

Get the call stack (backtrace) of the current thread. Shows return addresses, module names, and function names where available.

Inputs: sessionId (required), maxFrames.

get_cross_referencesA

Find all cross-references (xrefs) to or from the given address. Returns code references (calls/jumps) and data references (reads/writes).

Inputs: sessionId (required), address (required), direction.

get_exportsB

List all exported functions/symbols for a specific module.

Inputs: sessionId (required), module (required), nameFilter.

get_importsB

List all imported functions for a specific module. Shows DLL name, function name, ordinal, and IAT address.

Inputs: sessionId (required), module, dllFilter, functionFilter.

get_memory_mapA

Return the virtual memory map of the debuggee process: all regions with base address, size, protection, type, and associated module.

Inputs: sessionId (required), filterModule, filterProtection.

get_modulesA

List all modules (DLLs and the main EXE) loaded in the debuggee with base address, size, entry point, and file path.

Inputs: sessionId (required).

get_pe_headerA

Parse and return the PE header information for a module: DOS header, NT headers, section table, data directories, timestamp, subsystem, characteristics, etc.

Inputs: sessionId (required), module.

get_registersA

Read the current CPU register values of the active thread. Includes general-purpose registers, instruction pointer (RIP/EIP), flags, and optionally segment and debug registers. REQUIRES: session must be paused (call get_status to check). On x64: returns RAX, RBX, RCX, RDX, RSI, RDI, RSP, RBP, RIP, R8-R15. On x86: returns EAX, EBX, ECX, EDX, ESI, EDI, ESP, EBP, EIP.

Inputs: sessionId (required), includeSegment, includeDebug, includeFpu.

get_statusA

Query the current state of the debugger and active session. Returns bridge connectivity, session state (idle/paused/running/stepping/terminated), current instruction pointer, active thread, and a next-step hint. Call this whenever you are unsure what state the debugger is in before issuing step/continue/breakpoint operations. This is always safe to call — it does not change any debugger state.

Inputs: sessionId.

get_threadsB

List all threads in the debuggee process with their current state.

Inputs: sessionId (required).

list_breakpointsA

List all breakpoints in the session, including hit counts and conditions.

Inputs: sessionId (required).

list_functionsA

List recognised functions in the debuggee. Can filter by module name and/or name substring.

Inputs: sessionId (required), module, nameFilter, offset, +1 more.

list_sessionsA

List all active debugging sessions with their state and metadata.

Inputs: no named parameters.

load_executableA

START HERE — load a PE executable into x64dbg and create a debugging session. Returns a sessionId that ALL other tools require as their first parameter. Auto-detects 32-bit vs 64-bit PE and launches x32dbg or x64dbg accordingly. With breakOnEntry=true (default): execution stops at the entry point and the session state becomes 'paused' — you can immediately call step_into, get_registers, or disassemble. With breakOnEntry=false: the debuggee starts running; use set_breakpoint then continue_execution to pause it later. Only one session can be active at a time. Call terminate_session first if one exists.

Inputs: executablePath (required), commandLineArgs, breakOnEntry, autoAnalyze.

read_memoryA

Read raw bytes from the debuggee's virtual address space. Returns a hex+ASCII dump. Address must be in the debuggee's mapped memory (see get_memory_map for valid ranges). REQUIRES: session must be paused.

Inputs: sessionId (required), address (required), size.

remove_breakpointB

Remove a previously set breakpoint at the given address.

Inputs: sessionId (required), address (required).

run_to_addressA

Set a one-shot breakpoint at the given address and continue execution. Stops when the address is reached or another breakpoint/exception fires first.

Inputs: sessionId (required), address (required).

search_memoryA

Search the debuggee's memory for a byte pattern or string. Supports hex patterns with wildcards (e.g. '4D 5A ?? ??') and text strings.

Inputs: sessionId (required), pattern (required), searchType, startAddress, +2 more.

set_breakpointB

Set a breakpoint. Supports software BPs, hardware BPs (execute/read/write), and memory BPs. Optionally supply a condition expression or log text.

Inputs: sessionId (required), address (required), type, condition, +2 more.

set_registerC

Set the value of a single CPU register.

Inputs: sessionId (required), register (required), value (required).

step_intoA

Execute one or more instructions, stepping INTO function calls. REQUIRES: session state must be 'paused'. Returns the new address, disassembly, module, and key register values after stepping. Use step_over instead if you want to skip over CALL instructions.

Inputs: sessionId (required), count.

step_outA

Run until the current function returns (execute until RET). REQUIRES: session state must be 'paused'. Useful for quickly leaving a called function and returning to the caller without stepping through every instruction.

Inputs: sessionId (required).

step_overA

Execute one or more instructions, stepping OVER function calls. REQUIRES: session state must be 'paused'. If the current instruction is a CALL, the entire called function executes and control returns to the instruction after the CALL. Use step_into if you want to trace inside the called function.

Inputs: sessionId (required), count.

switch_threadA

Switch the active thread. Subsequent register/stack/step operations will apply to this thread.

Inputs: sessionId (required), threadId (required).

terminate_sessionA

Stop the debuggee process and close the debugging session. x64dbg itself stays open and ready for the next load_executable call. Call this before loading a new executable, or when analysis is complete.

Inputs: sessionId (required).

trace_executionB

Record an execution trace from the current position. Steps through instructions and records address + disassembly at each step. Stops after maxInstructions or a breakpoint.

Inputs: sessionId (required), maxInstructions, traceInto, recordRegisters, +1 more.

write_memoryA

Write bytes to the debuggee's virtual memory. Use with caution — writing to wrong addresses can crash the debuggee.

Inputs: sessionId (required), address (required), hexBytes (required).

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A3.8/5.0

    Scored across 39 tools

    Disambiguation4/5

    Most tools have distinct, well-defined purposes (e.g., step_into vs step_over, disassemble vs read_memory). However, tools like analyze_function and analyze_suspicious_apis could be confused if descriptions are not read carefully, and execute_command overlaps with other tools' capabilities.

    Naming Consistency5/5

    All tool names use a consistent verb_noun pattern in snake_case (e.g., analyze_function, load_executable, continue_execution). No mixed conventions or vague verbs.

    Tool Count4/5

    39 tools is on the higher end but justified by the breadth of debugger functionality. The tool set covers execution control, memory inspection, analysis, and session management without being excessive.

    Completeness5/5

    The tool set provides comprehensive coverage for a debugger/analysis server: loading, stepping, breakpoints, memory, registers, modules, security analysis, session management. No obvious gaps for typical reverse engineering tasks.

    Maintenance

    ActivityInactive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • F
      license
      Not graded
      quality
      C
      maintenance
      Enables AI-assisted reverse engineering and debugging through x64dbg integration. Provides 40+ tools for breakpoint management, memory operations, register manipulation, code analysis, process control, and advanced debugging features.
      22
      -
    • A
      license
      Not graded
      quality
      F
      maintenance
      Enables AI-driven reverse engineering with x64dbg via 71+ MCP tools for breakpoints, memory, disassembly, tracing, debug control, PE analysis, and anti-anti-debugging, supporting HTTP, SSE, and stdio transports.
      2
      MIT