Ghidra MCP Server

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.

Quickstart: install a release (no clone, no build)

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).

1. Install the prerequisites: Ghidra 12.1.4, Java 21 and uv. The extension only loads in the exact Ghidra version it was built for.

2. Install the extension: in Ghidra's project window, File > Install Extensions, click +, pick the GhidraMCP-<version>.zip you downloaded, and restart Ghidra.

3. 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"}
   

4. 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
   

5. 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.

Why Ghidra MCP?

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.

• 209 MCP tools — 3x more than any competing implementation. Not just read operations — full write access for renaming, typing, commenting, structure creation, script execution, P-code emulation, and live debugging.
• Battle-tested AI workflows — Proven documentation workflows (V5) refined across hundreds of functions. Includes step-by-step prompts, Hungarian notation reference, batch processing guides, and orphaned code discovery.
• Production-grade reliability — Atomic transactions, batch operations (93% API call reduction), configurable timeouts, and graceful error handling. No silent failures.
• Cross-binary documentation transfer — SHA-256 function hash matching propagates documentation across binary versions automatically. Document once, apply everywhere.
• Full Ghidra Server integration — Connect to shared Ghidra servers, manage repositories, version control, checkout/checkin workflows, and multi-user collaboration.
• Headless and GUI modes — Run with or without the Ghidra GUI. Docker-ready for CI/CD pipelines and automated analysis at scale.
• Opinionated by design — v5.0 moves naming conventions, type safety, and documentation standards into the tool layer. AI agents and human engineers produce consistent output without style guides in every prompt.

Convention Enforcement

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"