GhidraMCP vs IDA Pro MCP vs r2mcp: Reverse Engineering MCP Servers Compared

Short version: pick the MCP server that matches the disassembler you already use. GhidraMCP gives an AI agent Ghidra (free), ida-pro-mcp gives it IDA Pro (paid; IDA Free is not supported), r2mcp gives it radare2 (free), and the Binary Ninja plugins give it Binary Ninja (paid tier with plugin support). REA is a different shape: one server that drives Ghidra, Hopper or IDA for native code and also covers non-native targets (.NET, Electron, Android and others). On the same test binary, GhidraMCP and REA’s Ghidra provider returned byte-identical pseudocode, because both are Ghidra underneath; what differs is the wrapper.

How this was checked. I ran GhidraMCP 2.0 and REA 6.7.0 (Ghidra provider) on one self-built binary on an Apple Silicon Mac, on 2026-11-02. I did not run ida-pro-mcp (I have no IDA Pro licence), r2mcp or the Binary Ninja plugin; everything about those is desk research from their repositories and vendor pages, checked 2026-10-13 and listed under Sources. This site publishes REA tutorials, so weigh its REA notes accordingly; it is not affiliated with REA or any of these projects.

Hands-on: GhidraMCP and REA on the same binary

The sample is a 33,464-byte Mach-O arm64 hello-world I compiled with Apple clang 21 (clang -O1), SHA-256 f4f27f8a…6fafc914. It hashes its first argument and prints hello, friend or hello, stranger.

Setup that both needed

Both used Ghidra 12.1.4 with Temurin JDK 21.0.13, downloaded into a scratch folder. Two gotchas before anything ran:

• Ghidra 12.1.4’s release zip has no macOS decompiler binaries; Ghidra/Features/Decompiler/os/ holds only linux_x86_64 and win_x86_64. GhidraMCP’s README says to build them once: support/gradle/gradlew buildNatives (with JAVA_HOME on JDK 21). It finished in 18 s here with Xcode’s clang and wrote build/os/mac_arm_64/decompile. REA’s rea doctor --provider ghidra then reported ghidra-native_decompiler ... reports mach-o arm64, which matches darwin/arm64.
• Do not grab the newest Ghidra. 12.2 came out on 2026-10-22, but GhidraMCP 2.0 ships its extension built for 12.1.4, REA’s docs say its bridge is verified with 12.1.4, and REA’s installation notes say 12.2 needs JDK 25.

GhidraMCP 2.0, headless

GhidraMCP 2.0 has a headless mode that imports the binary itself through PyGhidra, so no Ghidra GUI is needed. I ran the bridge from the release wheel with the release’s extension JAR and spoke MCP to it over stdio:

export GHIDRA_INSTALL_DIR=/path/to/ghidra_12.1.4_PUBLIC
uvx --python 3.13 --from "ghidra-mcp[headless] @ file:///path/to/ghidra_mcp-2.0.0-py3-none-any.whl" \
  ghidra-mcp --headless --binary ./hello --extension-jar /path/to/GhidraMCP/lib/GhidraMCP.jar

It exposed 28 tools, including decompile_function, get_xrefs_to, rename_function_by_address, set_function_prototype and set_local_variable_type. Trimmed results:

get_program_info  -> "language_id": "AARCH64:LE:64:AppleSilicon", "function_count": 3,
                     "external_function_count": 2, "entry_points": ["100000460", "100000000"],
                     "sha256": "f4f27f8a515a31de487540dbee06481074f3c808a26e1133a127f6713fafc914"
list_functions    -> entry @100000460, _puts @1000004f0, _strlen @1000004fc
decompile_function {"name": "main"}
                  -> [FUNCTION_NOT_FOUND] No function found named 'main'
rename_function_by_address {"function_address": "100000460", "new_name": "main"}
                  -> {"old_name": "entry", "new_name": "main"}

Two practical notes. The binary does have a _main symbol (nm shows it at 0x100000460), but Ghidra labelled that function entry, the program’s entry point, and search_functions_by_name("main") came back empty. An agent that asks for main gets an error until it lists functions first. And the rename worked, but in headless mode it lives only in that session: on exit the server logged Discarding unsaved changes to hello. The README’s --project DIR flag keeps the project and saves changes between runs. The first run took about 20 s including the uvx download; a repeat run took 3.6 s for five calls.

REA 6.7.0, Ghidra provider

REA (a third-party open-source tool) uses the same Ghidra install through its own headless bridge:

export GHIDRA_INSTALL_DIR=/path/to/ghidra_12.1.4_PUBLIC JAVA_HOME=/path/to/jdk-21/Contents/Home
rea analyze ./hello --provider ghidra --json
rea decompile ./hello 0x100000460 --provider ghidra --json

analyze reported image_base 0x100000000, 9 segments, 5 procedures (the 3 local functions plus the 2 externals) and 17 defined strings, in 5.3 s. decompile took 5.2 s, because each CLI call imports the binary into a fresh, throwaway Ghidra project. Its pseudocode was byte-identical to GhidraMCP’s (711 characters, compared programmatically):

undefined8 entry(int param_1,long param_2)
{
  ...
  if (param_1 < 2) {
    uVar4 = 2;
    pcVar2 = "usage: hello <word>";
  }
  else {
    pbVar5 = *(byte **)(param_2 + 8);
    sVar1 = _strlen((char *)pbVar5);
    if (sVar1 == 0) {
      uVar4 = 0;
      pcVar2 = "hello, stranger";
    }
    else {
      iVar3 = 0;
      do {
        iVar3 = (uint)*pbVar5 + iVar3 * 0x1f;
        sVar1 = sVar1 - 1;
        pbVar5 = pbVar5 + 1;
      } while (sVar1 != 0);
      uVar4 = 0;
      pcVar2 = "hello, friend";
      if (iVar3 != 0x5f2a1c3b) {
        pcVar2 = "hello, stranger";
      }
    }
  }
  _puts(pcVar2);
  return uVar4;
}

What REA added around it: an evidence_id, the target’s SHA-256, the exact Ghidra version and analysis settings, "confidence": "observed", and a list of limitations, such as “Pseudocode is Ghidra decompiler output, not original source” and that the temporary project is deleted on close.

What the comparison shows

• Same engine, same answer. If both servers sit on Ghidra 12.1.4, the decompiler output is the same. Choose on the wrapper, not on “which one decompiles better”.
• Session model. GhidraMCP keeps one analysed program open for the life of the server (or attaches to your GUI), so follow-up calls are fast and you can rename things. REA’s CLI re-imports per call, and its Ghidra edits are limited to function names and entry comments that are discarded on close; in exchange every result carries hashes and stated limits.
• Tool surface. GhidraMCP exposes Ghidra’s read-and-annotate loop directly (28 tools). REA’s Ghidra provider is narrower on edits but adds non-Ghidra targets.

IDA Pro MCP: what I could not test

ida-pro-mcp needs IDA Pro 8.3 or later (9 recommended), and its README says plainly that IDA Free is not supported. I have no IDA Pro licence, so I did not run it, and nothing below is first-hand. Per its README (rechecked 2026-11-02), the recommended mode is idalib-mcp, a headless supervisor that keeps each database in its own idalib worker; the GUI plugin “is no longer recommended”. Tool groups include decompile/disassemble/xrefs, comments, patching, types, stack frames, a debugger extension and py_eval. The README now opens with “I recommend using the Official Hex-Rays IDA MCP Server instead!” (HexRaysSA/ida-mcp, which requires IDA 9.4+ with idalib). The last GitHub release is still 1.4.0 (2025-10-06), with active commits on the default branch.

If you plan to put IDA behind REA instead: REA 6.7.0’s default attached mode expects ida-pro-mcp 1.4.0 tool names and does not work with the 2.0-style tools that upstream’s main now installs (REA issue #2301). Pin it with python3 -m pip install "ida-pro-mcp==1.4.0" "mcp<2", or use REA’s "protocol": "native" mode. rea doctor --provider ida only validates the registration file, so it can report healthy against an incompatible plugin. I did not test either path.

Comparison table (desk research, checked 2026-10-13)

“Engine cost” is the cost of the underlying disassembler, not the MCP server. Rows marked as run are the only first-hand ones.

Engine pricing from vendor pages, checked 2026-10-13: Hex-Rays lists IDA Free at no cost, IDA Home from $365/year and IDA Pro from €1,099/year (pricing); whether IDA Home works with ida-pro-mcp is not verified. Vector35 lists Binary Ninja Free ($0, no plugins), Personal ($199, plugins in the GUI only), Commercial ($1,799, headless) and Ultimate ($3,499) (purchase). Vector35 also documents a beta Sidekick MCP server (docs), not evaluated here.

From the READMEs: r2mcp runs as a stdio server, an r2 core plugin or an HTTP server with optional bearer-token auth, and has read-only and sandbox switches plus optional raw r2 command or r2js execution. The Binary Ninja plugin exposes HLIL, MLIL and LLIL, strings, xrefs and multiple open binaries. REA’s non-native coverage (Electron, .NET, Android, web captures, firmware) has per-target prerequisites, and several targets are Linux-only.

Which one fits?

• You already work in IDA Pro: ida-pro-mcp, or Hex-Rays’ official IDA MCP on IDA 9.4+.
• You want a free stack on Ghidra: GhidraMCP. Its headless mode worked on macOS once the decompiler natives were built.
• You live in radare2 or want a small C server with read-only and sandbox switches: r2mcp.
• You have Binary Ninja Personal or above and want IL-level access: the Binary Ninja MCP plugin.
• Your targets are mixed (a native helper plus an Electron app, an APK, a .NET DLL), or you want hashed, repeatable results: REA. See getting started with REA MCP.

Running more than one is fine; give each server a distinct name in your client config, since similar tool names confuse agents. Bind HTTP servers to loopback and only analyze software you are authorized to examine.

Sources

Hands-on runs: 2026-11-02 (Ghidra 12.1.4, JDK 21.0.13, GhidraMCP 2.0, REA 6.7.0, macOS on Apple Silicon). Desk research: 2026-10-13, with GhidraMCP, ida-pro-mcp and Ghidra release facts rechecked 2026-11-02.

• GhidraMCP: repository, releases
• Ghidra: releases
• ida-pro-mcp: repository; Hex-Rays IDA MCP: repository, announcement
• r2mcp: repository
• Binary Ninja MCP: fosdickio/binary_ninja_mcp, Sidekick MCP server docs
• REA: README, installation, Ghidra provider, IDA provider
• Pricing: Hex-Rays, Binary Ninja