x64DbgMCPServer: putting an LLM client in front of the x64dbg debugger

A plugin that turns x64dbg into an HTTP command server

The plugin is described as a starting point for building an MCP server plugin for x64dbg, using C# on the classic Windows-only .NET Framework platform, with no ASP.NET Core hosting required. That last clause is the design decision that shapes everything else.

Instead of hosting a web framework, the plugin runs a simple HTTP listener and exposes commands through a text-based API. The description calls it a lightweight HTTP interface bridge between an MCP client and the debugger, which lets an LLM MCP client send commands to inspect memory, disassemble, query registers and manipulate labels and comments, remotely and programmatically.

The feature list names the pieces: a self-hosted HTTP command interface with no ASP.NET Core, a lightweight zero-dependency binary deployment, modular commands with parameter mapping, direct interaction with registers, memory, threads and disassembly, bi-directional AI and LLM command support, plugin reload without restarting x64dbg, and support for expression functions and menu extensions.

The bi-directional point deserves a note. The obvious direction is the model sending commands into the debugger. The other direction is the debugger telling the model something, and expression functions and menu extensions are the mechanism for that, which is what makes the plugin more than a one-way command pipe.

On top of the bindings to the x64dbg engine, the project offers a clean project structure, a built-in command system and the HTTP listener, which is what makes it usable as a template rather than only as a tool.

Cursor connects over SSE with one JSON block

The client configuration is the shortest part of the setup, and it is a plain JSON object with a URL.

For Cursor the configuration is:

{
  "mcpServers": {
    "AgentSmithers X64Dbg MCP Server": {
      "url": "http://127.0.0.1:50300/sse"
    }
  }
}

The server is reached over SSE on port 50300, bound to the loopback address. The server name is free text, and the documentation shows a couple of variants, so nothing in the configuration ties the name to the plugin.

The URL is the important part. It is an http URL pointing at the local machine, which means the port has to be free and, as the troubleshooting section later explains, the process has to be allowed to listen on it. A port collision on 50300 is the first thing to check if a client reports that the server is unreachable.

Because the interface is HTTP rather than a pipe, the same endpoint is reachable from another machine on the network. That is convenient for a debugger running in a virtual machine while the agent runs on the host, and it is also a decision to make deliberately rather than by accident, since the documentation's example is loopback and nothing in it describes authentication.

Claude Desktop and Windsurf need a stdio to SSE bridge in between

For Claude Desktop and for Windsurf the configuration is different, and the documentation is explicit about why: an MCPProxy stdio to SSE bridge is required.

The Claude Desktop configuration names the proxy as the command and points it at the server address:

{
  "mcpServers": {
    "x64Dbg": {
      "command": "C:\\MCPProxy-STDIO-to-SSE.exe",
      "args": ["http://localhost:50300"]
    }
  }
}

Windsurf uses the same shape with a different server name:

{
  "mcpServers": {
    "AgentSmithers x64Dbg STDIO<->SSE": {
      "command": "C:\\MCPProxy-STDIO-to-SSE.exe",
      "args": ["http://localhost:50300"]
    }
  }
}

The proxy binary is a separate download, and the documentation links it as a repository of its own. The reason for the extra hop is that the plugin speaks SSE over HTTP while these clients expect to launch a local process and talk to it over stdio, so something has to translate.

The documentation also records a known problem: a context deadline exceeded timeout issue with directly using SSE. That is a candid note about the transport, and it is a reason to prefer the bridge where the bridge is available rather than a sign that the whole approach is fragile.

The build is a DllExport exercise, not a normal C# build

Building the plugin is where most of the setup time goes, and the reason is that the .NET assembly has to be exported as a native plugin that x64dbg can load.

The prerequisites are Visual Studio Build Tools, version 2019 v16.7 or later, the .NET Framework 4.7.2 SDK, and 3F/DllExport. The documented starting point is to clone or fork the project, then download DllExport.bat and place it in the root folder where the .sln file lives, and run it.

Inside the DllExport GUI the steps are to check the Installed checkbox, set the namespace for DllExport to System.Runtime.InteropServices, choose the target platform of x64 or x86, and click Apply.

After that you open the .sln solution file and build it. The documentation anticipates one specific failure: if you hit that error, clean and rebuild the DotNetPlugin.Stub, and the tree confirms why, since DotNetPlugin.Stub, DotNetPlugin.Impl and DotNetPlugin.RemotingHelper are three separate projects.

There is a naming step that is easy to miss. If you see x64DbgMCPServer.dll in the output folder, rename it to x64DbgMCPServer.dp64 so that x64dbg can load the plugin. Then the built files are copied into the x64dbg plugin directory, creating the plugin folder and a x64DbgMCPServer subfolder if they do not exist.

The 32-bit path has its own prerequisite: for x86 support you need .NET Framework 2.0 and .NET Framework 3.5 installed through the add or remove Windows components dialog, appwiz.cpl.

Starting the server and reading command results

Once the plugin is loaded, the documentation says to start the debugger, go to the plugins menu and click Start MCP Server, then connect with the preferred MCP client on port 50300 over SSE. The plugin can be reloaded without restarting x64dbg, which is what makes iterating on the plugin itself bearable.

The next part is a warning worth reading carefully, because it describes a genuine design problem in the x64dbg command surface: some x64dbg commands do not return meaningful booleans. The project therefore ships two helper commands that work around this.

ExecuteDebuggerCommandWithVar runs a command and reads a debugger variable afterwards. The documented example runs init notepad.exe and then reads $pid, polling every 100 milliseconds with a 5000 millisecond timeout, and a non-zero value such as 0x1234 means the process started. ExecuteDebuggerCommandWithOutput runs a command and captures the log output, with the example being the bplist command, and returns the log text the command produced.

So the pattern is: issue the command, then read the outcome from the debugger's own state rather than from a return value. That is a consequence of the debugger API, not of the model integration, and it is the thing to understand before writing anything that has to confirm an action actually happened.

A sample client is also published as a zip, and the documentation walks through it: edit line 590 in Program.cs to put in a Gemini API key from Google Cloud, edit line 615 to put in the MCP server address, and the prompt to execute sits on line 434.

Windows will not let you listen on that port without a reservation

The troubleshooting section documents a failure that is specific to Windows and worth understanding before you hit it. If the x64dbg log shows Failed to start MCP server: Access is denied, the cause is that Windows requires special permissions to listen on HTTP URLs.

There are two fixes. The quick one is to right-click x64dbg.exe and choose Run as administrator. The recommended one is to grant the URL permission from a command prompt running as administrator, using netsh:

netsh http add urlacl url=http://+:50300/ss

The recommended route matters for a workflow that involves an agent. Running the debugger as administrator gives every other part of the session administrative rights too, which is a poor default on a machine where an external process is going to be issuing debugger commands. The URL reservation grants the specific listener the specific right and nothing more.

Note that the URL in the reservation is http://+:50300/ss, while the client configuration points at http://127.0.0.1:50300/sse. The path differs, so confirm the exact reservation string against the troubleshooting section rather than guess at it, since a mismatched path leaves the access denied error in place.

What the repository actually contains, and what it is not

The tree is small and tells you what kind of project this is: a.sln file, the three DotNetPlugin projects, a Directory.Build.props, DllExport.bat in the root, an.editorconfig, and two files named Sample1 and Sample2 that hold sample conversations rather than code.

The samples show the intended usage. Sample1 is an AI tasked with loading a file, counting the internal modules and beginning to label important functions. Sample2 is about identifying a speedhack, which is a good illustration of the sort of analysis the interface is meant to support. A separate sample client project is published as its own repository and is described as a starting point for integration.

What the project is not is finished. The description calls it a starting point for building an MCP server plugin, and the feature list is a list of capabilities the template offers rather than a changelog of a mature product. The releases tell the same story, with tags v1.3, v1.5 and v1.6, and v1.6 and v1.3 both carrying the parenthetical about x64 and x32 bit support.

The licence is not stated in the repository metadata, and no licence file appears in the top-level entries, so anyone planning to build on this needs to establish the terms with the author rather than assume them.

The last push was on 2026-10-04, and the repository is not archived, so work is continuing on it.

Editorial conclusion

x64DbgMCPServer is worth a look for a reverse engineer who wants to ask a model for a disassembly listing or a memory read instead of typing it into the command line, because the plugin exposes the debugger through a plain HTTP command interface on port 50300 and ships the command helpers needed to make that interface usable, and because it can be reloaded without restarting the debugger. It is the wrong choice if you expected a production tool, because the project describes itself as a starting point, and it is the wrong choice for a non-Windows workflow, since the plugin targets the classic .NET Framework and x64dbg is Windows only. Before you build it, check the three things the documentation makes concrete: that the .NET Framework 4.7.2 SDK and the 3F/DllExport tool are installed, because the plugin is exported through DllExport and that step is not optional; that port 50300 is free and that you either run x64dbg as administrator or grant the URL reservation with netsh, or the server will fail to start with an access denied message; and that the x86 build needs the .NET Framework 2.0 and 3.5 components installed, which is a separate prerequisite from the 64-bit path.

Frequently asked questions

Official sources

1. AgentSmithers/x64DbgMCPServer on GitHub
2. Issues
3. README
4. Releases