REA MCP: setup, fixes, and a tested example

Short answer

Use the official rea-agents package to connect REA to a supported coding assistant. Preview setup before approving changes. Static JavaScript analysis needs no native disassembler. This guide does not establish direct REA support in OpenAI Dots.

What REA MCP does

REA means Reverse Engineer Anything. It provides tools for inspecting applications, native binaries, JavaScript packages, and runtime behavior. MCP, the Model Context Protocol, lets a compatible assistant call those tools.

Useful questions are specific: Which function handles this input? What does this packaged application expose? Which evidence supports the explanation? REA is an inspection tool, not a separate language model.

Use normal code tools when a source repository already answers the question. REA is useful when the evidence depends on a shipped package, a binary, or observed application behavior. Use software you own or are authorized to inspect. Official scope and responsible use.

Start with Node and the official package

This guide pins REA to 6.7.0. The npm registry reported this release on October 18, 2026. Its supported Node ranges are ^22.19.0 || ^24.11.0 || >=26.0.0. Node 23 and 25 are outside those ranges.

node --version
npm --version

Use a supported Node version before continuing. On our test computer, the default Node 23.9.0 was unsupported. An existing Node 24.19.0 runtime worked; we did not replace the system runtime.

npx rea-agents@6.7.0 --version

The tested command returned 6.7.0. npx can download the package into npm’s cache. A setup dry run avoids REA configuration writes; it does not prevent that download. Start from the official repository or official npm package.

Install REA for your client

Open the instructions for the client you use. Each set previews the plan, requests setup approval, then checks that client. You do not need to configure all three.

Setup normally registers the MCP server and installs its matching investigation skill. The skill contains workflow instructions; the server supplies callable tools. Installing only the skill does not connect MCP.

The home-folder shorthand ~ refers to your user directory. Environment overrides can change these locations. Use the actual paths in the setup plan. Do not replace a whole configuration file or add a duplicate REA server entry.

Setup can affect the selected client beyond the current project. Review the configuration files, skill destinations, and backup paths in the plan. Cancel if the scope is wrong. These client commands were checked against the release documentation; we did not apply them to three personal client configurations. Setup and client configuration.

Verify the connection before investigating

Restart the client named in the setup result. Open a new session and inspect its available tools. A successful doctor report checks configuration and prerequisites; it does not prove the running session has connected.

Ask the assistant for a bounded first task. Replace the sample path with an absolute path you can access:

Use REA to inspect /absolute/path/to/package.
Identify the entry point and exports.
Report evidence, coverage, and unknowns.
Do not execute the target.

Check that the assistant actually called a REA tool. Read its evidence and limitations. A prose answer without a tool call does not verify the connection.

For CLI-only static JavaScript analysis, use the tested package example below. A successful CLI run does not establish MCP registration in your client.

Choose an analysis engine only when needed

Static JavaScript and Electron package inspection does not require Hopper, Ghidra, or IDA. Linux also needs a procps-compatible ps command for the relevant process checks.

Deeper native-binary analysis needs a configured analysis engine. Check REA’s compatibility instructions before installing one. Ghidra needs a compatible JDK. Hopper and IDA have separate licenses; installing REA grants no entitlement to them.

REA setup does not install Node, Java, or Ghidra. Hopper installation is a separate optional approval. A missing native engine does not by itself prevent the JavaScript example below. Engine prerequisites.

Troubleshoot the failing layer

Start with the symptom you can observe. Keep unrelated client configuration and approval controls unchanged.

For native-provider diagnostics, list the discovered providers and capabilities. Then check only the engine you intend to use:

npx rea-agents@6.7.0 providers --json
npx rea-agents@6.7.0 capabilities --json
npx rea-agents@6.7.0 doctor --provider ghidra --json

Replace ghidra with hopper or ida for that engine. These queries do not install or switch engines. For Ghidra, confirm that its installation directory contains the headless launcher. Check that GHIDRA_INSTALL_DIR identifies that directory and JAVA_HOME identifies a compatible full JDK. For Hopper on macOS, open Hopper in the same user session and complete its demo or license prompt. If Apple Events access is denied, check the launching application under System Settings → Privacy & Security → Automation.

After a configuration change, repeat the failing check once. If it still fails, preserve the error and version instead of repeatedly reinstalling. Official readiness and troubleshooting.

Tested case: inspect a published JavaScript package

Our question was small: Does is-number@7.0.0 accept only decimal numbers, or other numeric strings too? We used the npm release artifact, not an application installed on a private account.

Environment: macOS arm64, Node 24.19.0, REA CLI 6.7.0. We downloaded the npm tarball, verified its registry SHA-512 integrity value, and extracted it without running an install script. The package’s MIT license is preserved in the evidence files.

To reproduce the artifact preparation in a new empty directory:

npm pack is-number@7.0.0 --ignore-scripts
tar -xzf is-number-7.0.0.tgz

npm pack creates an archive in the current directory. Extraction creates a package directory. The following POSIX-shell command inspects its selected files and saves the complete JSON result:

npx rea-agents@6.7.0 analyze-javascript-application ./package \
  --source-path index.js \
  --source-path package.json \
  --max-heap-mb 256 \
  --analysis-timeout-ms 30000 \
  --max-semantic-nodes 3000 \
  --max-semantic-nodes-per-file 3000 \
  --json > rea-evidence.json

On Windows, put this command on one line instead of using the backslash line continuations. ./package must point to your extracted directory. rea-evidence.json is the result file, not the target.

In our run, REA parsed one JavaScript file and reported no parse failures. Its export observation located the CommonJS default export in index.js, lines 10–18. Semantic analysis still reported unknowns. REA did not execute the package.

Reading the selected artifact showed separate number and string branches. Nonempty strings use numeric conversion and a finite-number check. That suggested hexadecimal and exponent strings could pass. We then tested that interpretation separately.

Cross-check the explanation with actual inputs

We executed the verified package in a separate Node process. All 12 recorded inputs matched the expected results. These checks are separate from REA’s static analysis.

A minimal independent check after extraction is:

node -e 'const n=require("./package"); for (const v of ["42","0x10","1e3","  ","12px"]) console.log(JSON.stringify(v),n(v));'

Expected output:

"42" true
"0x10" true
"1e3" true
"  " false
"12px" false

Read the recorded results, hashes, and analysis excerpt. The excerpt omits local machine paths and is not a portable full REA Evidence record. Repeating the command creates your own full record.

This is a small JavaScript package example. It does not validate native decompilation, every possible input, runtime capture, or installation in all three clients. The useful method is to inspect an artifact, state an interpretation, then test that interpretation independently.

Keep the evidence and privacy boundaries clear

REA analyzes targets locally, but your assistant receives tool results. The assistant’s model provider has its own data policy. Local analysis therefore does not mean every result stays on the computer.

Start with a public sample or software you are authorized to inspect. Keep credentials, customer files, and private binaries out of shared reports. Static inspection and runtime capture are different operations; confirm what will run before requesting runtime observation.

Keep the package version, artifact hash, environment, evidence, and unknowns with a result. An explanation can be useful while some behavior remains unresolved. Official FAQ and data boundaries.

FAQ