REA vs Ghidra MCP

Two ways to put an AI agent behind a disassembler. One is a purpose-built agent with its own analysis loop and evidence contract; the other is a bridge that lets any MCP-capable agent drive Ghidra. Here is how they differ in practice.

Ghidra MCP

  • Bridge server exposing Ghidra operations over MCP
  • Bring your own agent (any MCP client, e.g. an AI coding assistant)
  • You keep Ghidra's full UI, scripting, and headless modes
  • Best for: analysts already inside the Ghidra ecosystem

same target, two terminals

Lay out a binary you own, with each approach (outputs from our lab, 2026-10-12):

rea — evidence contract verified: ran 2026-10-12
$ npx rea inspect-binary-layout lab-env/hello
evidence_id: ev_6e479c83… / sha256 36cdabb6…
provider: pwntools-elf @ pwntools 4.15.0;pyelftools 0.33;unicorn 2.1.2
[✓] normalized_result: 31 sections, entry_point 0x400320
ghidra-mcp — tool calls from your agent
$ client asks: list functions referencing ".conf"
[mcp] ghidra.searchStrings(".conf") → 1 hit @ 0x1402
[✓] decompile(0x1402) returned to agent

verdict

CHOOSE REA IFYou are starting from zero and want one install that owns the whole loop — and you value evidence IDs over UI.
CHOOSE GHIDRA MCP IFYou already use Ghidra or a favorite agent, and want them connected rather than replaced.

faq

Can I use both?

Yes — they are not mutually exclusive. Many analysts keep Ghidra open for verification while letting REA drive exploration; REA itself uses Ghidra as one of its decompile engines.

Which handles large binaries better?

Ghidra's indexer scales better on very large binaries; agents shine at navigation and evidence capture, not raw indexing throughput. In our lab, REA's free engine handled a 4.5MB system library fine via JSON export.

Are either of these legal to use?

The tools are legal; the target determines legality. Use them on software you own, open-source binaries, official demos, or authorized targets — see our AUP.