bethington/ghidra-mcp

The problem

Reverse engineering a binary in Ghidra is a long chain of small, repetitive UI actions: decompile a function, list its callers, follow xrefs, rename symbols, write a plate comment, then repeat a few hundred times. Scripting has always been possible, but Ghidra's API is idiosyncratic enough that most analysts copy-paste the same handful of scripts or just click. This project exposes Ghidra's analysis and editing surface as an MCP server so an LLM client can drive those steps — and, critically, also write back (rename, retype, comment, create structs), not just read.

What's different

There are several Ghidra MCP bridges in the wild now, and most of them are thin read-only wrappers. This one goes much wider: the README claims 209 tools covering P-code emulation, live debugger control, and PCode-graph data-flow propagation, plus a headless mode for batch and CI use. The more interesting design choice is baking conventions into the tool layer — names, types and comment quality are checked with auto-fix / warn / reject tiers, and an analyze_function_completeness score gives the agent (or you) a target. That is a real departure from the usual "let the model invent style" approach, and it is the part most likely to matter in practice, because consistency is what breaks down first when you hand naming to a model. It also ships documentation-transfer by function hash across binary versions, which is a workflow feature rather than an API feature.

Who it's for

Malware analysts, vulnerability researchers and firmware/embedded reverse engineers who already live in Ghidra and want an LLM as a fast assistant on decompilation reading and annotation triage. Teams doing versioned analysis across firmware builds will get the most out of the documentation-transfer and Ghidra Server features. It is not for people who don't already know Ghidra — the setup expects you to install an extension, match the exact Ghidra version, and debug a bridge; and it is not a substitute for understanding assembly, because the model still has to be checked.

Cost of adoption

Heavy. You need Ghidra pinned to exactly 12.1.4 (the extension only loads in the version it was built for), Java 21, Python 3.10–3.13 and uv, plus an MCP-capable client. Installation is via a release zip and a wheel — see the README's quickstart, which includes a single uv tool install command. Two operational gotchas are called out: GUI-launched clients don't inherit your PATH, and release candidates / main / dev branches differ in stability. Apache-2.0 is friendly, and the version churn is high, so budget time for upgrades whenever Ghidra moves.

Verdict

This is not a brand-new experiment: it has over 5,800 stars, a working release pipeline with tests, and a Show HN thread at 298 points, all built in roughly 14 months. The signal that matters is the +1,948 stars in a single month on the Java monthly board — interest is clearly rising rather than fading, which fits the general MCP gold rush and means the API will keep moving under you. The 209-tool surface is impressive but also a maintenance liability, and the convention-enforcement layer is the genuinely opinionated bet here. If you already know Ghidra and want an LLM annotating alongside you, it is the most complete option; if you want something stable to build on, wait for tagged releases to settle.