Security & privacy

REA - One MCP Server for Reverse Engineering With AI Agents

REA is an MCP server that lets an AI agent drive reverseengineering tools. Its repository describes it as "one MCP for reverse engineering across binaries, applications, and runtime behavior," and frames the use case...

REA - One MCP Server for Reverse Engineering With AI Agents

REA is an MCP server that lets an AI agent drive reverse-engineering tools. Its repository describes it as “one MCP for reverse engineering across binaries, applications, and runtime behavior,” and frames the use case more concretely: “See a feature you like. Understand how it works, down to the binary level.”

The npm package is rea-agents, the project is MIT licensed, and the same workflows are available either through an agent over the Model Context Protocol or directly from a terminal via a rea CLI.

What it actually is

The most useful thing to understand about REA is what it does not do: it is not a decompiler. For native binaries, the README states it requires Hopper, Ghidra, or IDA. Android work needs JADX and a JDK, or adb for devices. Website analysis needs a Chrome-family browser.

REA is the connective layer above those tools — one interface that an agent can call, instead of a dozen incompatible ones with their own output formats and scripting dialects. That is a sensible division of labour. Decompilation is a solved and heavily engineered problem; orchestrating decompilers and keeping track of what was found across a multi-step investigation is not.

The practical consequence is that your results depend on a toolchain you install yourself. REA will not conjure pseudocode out of a stripped binary if no decompiler is present.

What it can look at

The documented target types are unusually broad:

  • Native binaries — pseudocode, assembly, strings, symbols, and references, via Hopper, Ghidra, or IDA.
  • JavaScript and Electron apps — modules, imports, source maps, routes, IPC, and native add-on relationships.
  • .NET assemblies — metadata, CIL instructions, and build comparisons, documented as static only.
  • Android — APK manifests and decompiled methods through JADX, or device logs and transfers through adb.
  • Websites — page structure, scripts, network observations, and screenshots.
  • Everything else — ELF layouts, WASM, EVM bytecode, recorded Linux crashes, firmware, saved network captures, JEB projects, Apktool resources, Apple app bundles, and process behaviour, each with its own stated requirements.

That spread is the argument for the project existing. An investigation that starts in an Electron bundle and ends in a bundled native add-on currently means switching tools and losing context at every boundary.

The design detail worth noticing

Agents are confidently wrong about binaries more often than about most things. Pseudocode is dense, partially reconstructed, and full of compiler artefacts that invite plausible-sounding narration.

REA’s stated answer is that analysis runs locally and that results “include the evidence and limitations behind each conclusion.” Returning the basis for a finding alongside the finding, rather than a bare assertion, is the right structural response to that failure mode — it gives both the agent and the person reading the transcript something to check against. Whether it holds up under pressure is something you would want to verify on a target you already understand, which is a reasonable way to evaluate any tool of this kind.

Static versus runtime

This distinction deserves more attention than its one line in the README, because it is where the operational risk sits. Static inspection of JavaScript and .NET, the documentation says, “read the supplied files without running the application.”

Runtime capture is different: it “runs or interacts with the selected target using your user permissions.” So pointing REA’s runtime features at an unknown binary means executing that binary on your machine with your own privileges. That is inherent to dynamic analysis rather than a flaw in REA, and it is the standard reason this work belongs in a virtual machine or a disposable container rather than on your working laptop.

Getting started

Registering the MCP server with an agent is a single command:

npx rea-agents setup

The documented agents are Claude Code, Codex, Cursor, Gemini CLI, and Grok Build, and the FAQ states that any agent supporting local MCP servers can use it. For terminal use there is a global install:

npm install --global rea-agents
rea --help

Individual workflows can also be run directly, for instance against an Electron app:

npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json

Node version requirements are specific: 22.x from 22.19, 24.x from 24.11, or 26 and newer. Global installs update with rea update.

The part you cannot skip

Reverse engineering is lawful in many contexts and restricted in others, and which applies depends on your jurisdiction, the licence terms of the software, and what you intend to do with the result. Interoperability research, security analysis of software you run, and examining your own devices sit on very different footing from redistributing a reconstruction of someone else’s product.

The project states its position plainly: “REA provides tools for lawful reverse-engineering research, analysis, and reconstruction,” with users responsible for obtaining the required authorisation and complying with applicable law. That is the correct framing, and it is worth treating as a real precondition rather than boilerplate — a tool that lowers the effort of reverse engineering by this much makes it easy to get further into a target than you have the right to be.

As a side note that says something about the project’s visibility: the README also states that it has not issued or endorsed any cryptocurrency or token. Popular repositories attract impersonation, and spelling that out is a reasonable precaution.

Verdict

REA is a well-judged piece of plumbing. It does not try to out-engineer Ghidra; it makes the existing toolchain addressable by an agent and insists on returning evidence with its conclusions. If you already do this work and already have the decompilers installed, the setup cost is one command. Keep runtime analysis in a disposable environment, verify the tool against something you know before trusting it on something you do not, and be clear about your authorisation before you start.

Learn more at: https://github.com/morluto/rea

Share

XLinkedIn