MCP server bridging Ghidra's reverse engineering with AI tools: 256 tools for decompilation, P-code emulation, live debugging, data flow analysis, batch operations, and convention enforcement across headless and GUI modes.
If you find this useful, please ⭐ star the repo — it helps others discover it!
If Ghidra MCP saves you time, consider sponsoring the project. One-time and recurring support both help fund compatibility updates, production hardening, docs, and new tooling.
A production-ready Model Context Protocol (MCP) server that bridges Ghidra's powerful reverse engineering capabilities with modern AI tools and automation frameworks. 209 MCP tools, battle-tested AI workflows, and the most comprehensive Ghidra-MCP integration available — now including P-code emulation, live debugger integration, and PCode-graph data flow analysis.
Every release ships the two
pieces you need: the Ghidra extension (GhidraMCP-<version>.zip) and the MCP
bridge (ghidra_mcp_bridge-<version>-py3-none-any.whl).
Install the prerequisites: Ghidra 12.1.4, Java 21 and uv. The extension only loads in the exact Ghidra version it was built for.
Install the extension: in Ghidra's project window, File > Install
Extensions, click +, pick the GhidraMCP-<version>.zip you downloaded,
and restart Ghidra.
Enable the plugin: in the project window, File > Configure > Utility > Configure, tick GhidraMCPPlugin. Check it answers:
curl http://127.0.0.1:8089/check_connection
# {"status": "ok", "server_kind": "gui", "version": "7.0.0"}
Install the bridge (copy the wheel's link from the same release page):
uv tool install https://github.com/bethington/ghidra-mcp/releases/download/v7.0.0/ghidra_mcp_bridge-7.0.0-py3-none-any.whl
Point your MCP client at it, using the absolute path (which bridge-mcp-ghidra, or where.exe bridge-mcp-ghidra on Windows):
{
"mcpServers": {
"ghidra-mcp": { "command": "/home/<you>/.local/bin/bridge-mcp-ghidra" }
}
}
On Windows: "command": "C:\\Users\\<you>\\.local\\bin\\bridge-mcp-ghidra.exe".
A client launched from a GUI or a service does not see your shell's PATH,
so a bare bridge-mcp-ghidra fails with spawn ENOENT.
Open a program in Ghidra and ask your AI tool to list its functions. Screenshots of steps 2-3: docs/INSTALL_GUI.md. Building from source, Docker, the HTTP transports and every bridge flag are further down.
Which version should I run? Tagged releases (7.0.0, 7.1.0, ...) are
stable. Release candidates and main are beta: feature-complete and
live-tested, but shapes can still change before final. dev is experimental:
tools are merged, renamed and refactored there freely, so build nothing on its
API.
Most Ghidra MCP implementations give you a handful of read-only tools and call it a day. This project is different — it was built by a reverse engineer who uses it daily on real binaries, not as a demo.
You've been there: six months into a project you find ProcessItem, process_items, handleItem, and ItemProc in the same codebase — four functions doing the same thing, named by four different sessions or engineers with no shared contract. Fixing it takes longer than it should, and the problem will happen again.
v5.0 moves conventions from "things to remember" into the tool layer, where they can actually be enforced.
| Tier | Behavior | Example |
|---|---|---|
| Auto-fix | Applied silently | count field on a uint32 → auto-prefixed dwCount on save |
| Warn | Change goes through, warning returned | processData → "name should be PascalCase with a verb: ProcessData" |
| Reject | Change blocked with explanation | undefined → undefined type change → "no-op rejected, type unchanged" |