REA is distributed as one npm package, rea-agents, but it is useful to think of it as six parts. Knowing which part does what makes installation problems and capability questions much easier to reason about.

The command-line interface

The rea command is the primary surface. It groups more than 150 subcommands by target: JavaScript and Electron applications, Apple bundles and property lists, Android packages and resources, native binaries through a provider, firmware, captures, databases, and the project's own diagnostics. Every command accepts --json for machine-readable output, and the same commands are what the MCP server calls internally. If something works in the terminal, it works for an assistant, and the reverse.

Install it globally with npm install --global rea-agents, or run one-off commands with npx -y rea-agents@latest <command>.

The MCP server

rea mcp starts a Model Context Protocol server over standard input and output. The client, such as Claude Code, Cursor or Codex, launches the process on the same machine and talks to it through pipes. There is no HTTP listener and no network port, which is why REA works out of the box with desktop clients and does not work directly with hosted assistants such as ChatGPT on the web. Bridging that gap is what our dedicated REA MCP endpoint adds.

The server exposes the CLI workflows as MCP tools. Tool names and parameters follow a stable contract documented in the upstream repository, and tool results carry the same evidence structure as the CLI's JSON output.

Analysis providers

REA does not reimplement disassemblers or decompilers. It wraps existing engines, called providers, and normalises their output. The main ones:

  • Native code: Ghidra, Hopper or IDA for pseudocode, assembly, symbols and references. Ghidra is open source and runs headless with a Java 21 runtime. Hopper and IDA are commercial and need their own licenses. Kuna is a static decompiler REA can also drive. For offline inspection without a full engine, REA accepts GNU objdump and Rizin.
  • Android: headless JADX with a full JDK for classes and decompiled methods, Apktool for decoded resources, and adb for devices and emulators.
  • JavaScript and Electron: built-in parsers for bundles, ASAR archives, source maps, routes and IPC bridges. No external engine is needed.
  • Apple applications: built-in readers for bundles, property lists, keyed archives and Interface Builder documents.
  • Managed and other formats: built-in static inspection for .NET assemblies, Go and Rust binary metadata, Flutter snapshots, WebAssembly through WABT, EVM bytecode and SQLite databases.
  • Captures and recordings: HAR and SAZ files, mitmproxy and TShark for network traffic, sigrok for logic analyser recordings.
  • Firmware: Binwalk or Unblob on Linux for extraction, then native providers for the extracted code.
  • Runtime observation: a Chrome-family browser for websites, Frida for instrumentation, native pseudo-terminals for process capture.

REA does not install or update any of these. You install the ones your targets need, and REA detects them or reads their location from environment variables.

Agent setup and the skill

npx rea-agents setup registers the MCP server with the agents you choose and installs a matching skill: workflow instructions that teach the assistant how to investigate with REA, when to ask for authorization, and how to present evidence. Supported agents include Claude Code, Codex, Cursor, Gemini CLI and several others. Setup shows a diff of the configuration changes and backs up existing files before writing. rea update keeps the installation current and prints the setup command to refresh registrations.

Readiness checks

rea doctor reads the host prerequisites, the agent registrations and the configured providers, and reports what is ready for a given task. It returns a non-zero exit code when a required check fails, which makes it usable in scripts and CI. Provider-specific diagnostics, for example rea doctor --provider ghidra --json, show exactly which binary, Java runtime or version check is missing. When an assistant says a target cannot be analysed, the doctor output is usually where the answer is.

Evidence and artifacts

Every analysis records what it read: artifact identities and digests, the provider and version that produced a result, and whether the result is complete. Snapshots let you save a provider's state for a binary and come back to it, and comparison commands work across two builds of the same application. This bookkeeping is what lets the investigation loop stay honest over many steps, and it is also what a hosted service must preserve when it moves the tools to a server.