REA gives an agent a reverse engineering toolchain over MCP

One tool for binaries, applications and runtime behaviour

The framing of the project is a single sentence in the README: one MCP for reverse engineering across binaries, applications and runtime behaviour. The use case it opens with is specific. You see a feature in an app that you would like in your own product, and you ask your agent to investigate it with REA. The README is clear about what that means in practice, since REA can inspect the app without its source code, explain how the feature works, show the evidence, and build a version for your project. REA connects the agent to tools for inspecting native binaries, JavaScript and Electron apps, .NET assemblies and websites, and the same tools are usable from a terminal. The important property is that the analysis runs locally and that the results include the evidence and the limitations behind each conclusion, which is what separates this from asking a model to guess what a binary probably does.

Setup registers the server and the instructions together

The installation path is a single command, and it is worth understanding what it does before running it. With Node.js and npm installed, the README says to run:

npx rea-agents setup

You choose your agents, review the proposed changes, and approve them. Setup adds REA's MCP server and the matching workflow instructions, with backups of the existing configuration, and you restart your agent afterwards. The supported agents are Claude Code, Codex, Cursor, Gemini CLI, Grok Build and others, with the installation documentation covering provider configuration and manual MCP registration for the cases the setup command does not cover. That review step is the point of the design. A setup that writes into your agent's configuration without showing you the diff is a setup you cannot review, and this one shows you the changes, backs up what was there, and waits for approval.

The loop is ask, inspect, trace, then implement

The mechanism is a loop rather than a one-shot analysis. Your agent calls REA through MCP to inspect the target and trace the relevant code, and REA returns findings with their evidence. The agent then uses those findings to ask follow-up questions, explain the behaviour, or write and test an implementation. The CLI commands use the same workflows, so a finding you reach in an interactive session and a finding you get from a script are produced the same way. The example prompt in the README shows the shape of a request, asking the agent to understand how search works in a named app, show the evidence, and build a similar feature for your project. The evidence requirement is the load-bearing part of the design, since a conclusion without a reference to the code that produced it is not something a reviewer can check.

Native targets need an engine, static JavaScript needs none

The requirements vary sharply by target, and the table in the README makes the split clear. For native binaries, REA returns pseudocode, assembly, strings, symbols, calls and references, and the requirement is Hopper, Ghidra or IDA, with a linked guide for native analysis. For an application whose code is JavaScript or an Electron bundle, static analysis needs neither engine, and the README says so explicitly. The engine question also applies to setup. Native analysis can use an existing Hopper or Ghidra installation, and setup can optionally install Hopper with your approval. The runtime requirement for REA itself is Node.js 22.x at 22.19 or above, 24.x at 24.11 or above, or 26 and later, plus npm, and the package manifest declares the same range.

The terminal path, and the global install

The CLI exists on its own for the cases where an agent is not in the loop. To inspect an extracted JavaScript or Electron application directory or ASAR, the README gives:

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

The result includes modules, imports, Electron boundaries and their evidence, and the path is absolute, with the note that a Windows path would look like `D:/apps/example`. For regular use you can install the `rea` command globally and check it works:

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

Native analysis needs a provider configured first, and the README points at the CLI and evidence guide for the native commands, provider selection, snapshots and scripting. The `rea` and `rea-agents` binaries are the same script, `scripts/rea.mjs`, which is what the manifest registers.

Updates are a separate step from the analysis

REA changes quickly and the README says new releases include frequent bug fixes, so it tells you how to keep an installation current. For an npm-installed CLI:

rea update

That refreshes the tool, and then you run the setup command printed by the update to refresh the agent registrations and the skill, and review the setup changes and restart the agent. If you use `npx` rather than a global install, the equivalent is:

npx rea-agents@latest setup

and for one-off CLI commands you use `npx rea-agents@latest` followed by the command. The split between updating the CLI and updating the registration is the detail that matters in practice, because an updated CLI with a stale agent registration is a configuration that quietly keeps the old behaviour.

The bridge directory is where REA meets each engine

The repository layout shows how the tool reaches into different analysis environments. The `bridge/` directory holds the adapters, and the package manifest lists the files that ship: a Hopper bridge in Python, native UI helpers in Swift, a process run token reader in Swift, a Ghidra bridge and extensions in Java, a JADX bridge for Android, and a mitmproxy capture script. Alongside them are `native/`, `src/`, `scripts/`, `skill-src/`, `tests/`, `docs/`, `third_party/` and a `website/` directory, which is where the site and guides live. The project also has an `AGENTS.md`, a `CLAUDE.md`, a `SECURITY.md` and a `CHANGELOG.md`, uses release-please for versioning, and carries a `knip.json` configuration for unused code checks, so the repository is set up for an agent workflow on both ends.

MIT licensed, with a package name and a repository path that differ

The licence is MIT, and the npm package is published publicly under the name `rea-agents` with the description of a tool that reverse engineers anything from your terminal or agent with one CLI and MCP server. The manifest declares an MCP name of `io.github.morluto/rea`, and both the repository field and the homepage in the manifest point at a `morluto/rea` path, while the package keywords list reverse engineering, binary analysis, agent skills, MCP server, static analysis, disassembler, decompiler and Hopper. The last push to this repository was on 2026-10-08 and there are no GitHub releases, so the version you install comes from npm, where the manifest version is 6.0.0. There is a Discord community linked from the README, plus a website, guides and showcases, and the README carries a `current-status` anchor for the state of the project.

Editorial conclusion

Adopt REA when you need to understand a feature that only exists in a shipped binary or app, because the tool inspects the target locally, returns the evidence behind each conclusion, and hands the agent enough to write and test a replacement. Do not adopt it as a way to bypass licensing on code you do not own, and do not expect it to work on a target you cannot legally inspect, since the analysis is a local inspection of the artifact in front of you. Verify first which engine you will use for native targets, because that path needs Hopper, Ghidra or IDA installed, while the static JavaScript path needs neither, and check the Node version requirement before you start, since the package declares `^22.19.0 || ^24.11.0 || >=26.0.0`.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. NabilRFG12/Reverse-Engineer-anything on GitHub
4. Project website
5. README