REA vs GhidraMCP: which reverse-engineering MCP fits your work?

Both projects let an AI agent drive a disassembler over the Model Context Protocol, and both work with Ghidra. They are built for different jobs, though, and you can run them side by side. This comparison sticks to what each project documents; nothing here is benchmarked.

The short answer

• GhidraMCP is a focused bridge into Ghidra. If you live in the Ghidra GUI and want an agent to decompile, list and rename things inside the project you’re working on, it does exactly that.
• REA is one MCP for many kinds of targets. Ghidra is one of several engines behind it, next to Hopper and IDA — and a large part of REA works with no disassembler at all (Electron, websites, .NET, Android). Every result comes back as evidence with its limits spelled out.

Side by side

As documented on 2026-10-12: REA npm 6.4.0, GhidraMCP README on main.

Working with Ghidra

GhidraMCP

You install a release ZIP through File → Install Extensions, enable the plugin, and Ghidra serves an HTTP API that the Python MCP server talks to. The agent works on the program open in your Ghidra window, so renames show up where you’re looking. A headless mode imports and analyzes a binary with PyGhidra instead; add --project DIR to keep changes between runs.

REA

REA uses an extracted Ghidra 12.1.x with a matching JDK (21+ for current releases) — no plugin step. Point it at the install and let doctor check it:

export GHIDRA_INSTALL_DIR=/absolute/path/to/ghidra_12.1.4_PUBLIC
npx -y rea-agents@latest doctor --provider ghidra --json
npx -y rea-agents@latest decompile /absolute/path/to/program 0x1000 --provider ghidra --json

The Ghidra adapter exposes 25 read-only operations — inventory, search, decompilation, assembly, calls, typed references, data types, memory and file offsets. On Linux and macOS it can also rename functions and addresses and add comments, but those edits live in REA’s session and are discarded when it closes. If Hopper or IDA is installed too, you choose per session with --provider or provider_id.

Results & evidence

This is the biggest design difference. REA wraps each answer in an evidence record — subject digest, provider, parameters, locations, coverage and limitations — and records what it could not determine as explicit unknowns. An agent can tell an observed fact from an inference, and you can export the evidence and check it later.

GhidraMCP returns Ghidra’s output directly: decompiled code, lists of functions, classes, imports and exports. That’s lighter and maps one-to-one onto what you’d see in Ghidra — the right trade-off for interactive work where you are the one checking.

Setup in Claude Code

REA — setup registers the server and installs its workflow skill:

npx rea-agents@latest setup

GhidraMCP — with Ghidra running and the plugin enabled:

claude mcp add ghidra -- uvx --from git+https://github.com/LaurieWired/GhidraMCP ghidra-mcp --ghidra-server http://127.0.0.1:8080/

They register under different names (rea, ghidra), so both can be active at once. Each adds tool definitions to your context; REA’s catalog is large, so see the compact profile tip if you use a third-party endpoint.

Which one should you use?

• Annotating a Ghidra project with an agent → GhidraMCP. Its renames persist in your project.
• The target isn’t a native binary (Electron, a website, a .NET DLL, an APK) → REA.
• You use Hopper or IDA, or switch between engines → REA.
• You need to show your work — reconstructions, audits, write-ups → REA’s evidence records.
• Exploring a binary in Ghidra and also tracing the app around it → run both.

See how people combine them in practice: browse reverse-engineered native binaries and games in the directory.