REA, short for Reverse Engineer Anything, gives an AI assistant tools to investigate software through MCP. Instead of pasting isolated snippets into a conversation, you can ask the assistant to inspect an authorized target, follow relevant relationships, and explain the evidence it finds. The reviewed version runs locally, with capabilities determined by your target, installed analysis tools, and client setup.

The original project is morluto/rea. Our apitoagents/rea fork inherits its existing MCP server; the upstream authors deserve the credit for that implementation. At our October 14, 2026 review, the fork was at commit ca7450b, without additional fork-specific commits. This article explains the current project, not a newly launched hosted connector. The REA project page brings the repositories and setup options together.

Use REA only for lawful, authorized work, and only with applications or services whose terms permit the intended analysis. Permission must cover the target, data, and operations. The upstream responsible-use disclaimer explains that boundary. Neither installing REA nor having access to a file gives permission to bypass access controls, license checks, or payment restrictions.

What REA adds to the conversation

An assistant can reason about what you describe. An MCP tool lets it request a specific operation and receive its result. With REA, those operations can involve application structure, binary analysis, or runtime evidence. The assistant chooses follow-up questions; the analysis tools supply observations that you can inspect.

Three useful starting points are:

The useful outcome is a traceable explanation. It might identify which part of your application needs closer inspection, narrow a regression investigation, or help document an allowed integration. It does not guarantee complete source recovery or automatically prove that a suspected path actually executed.

Example: understand the export workflow in your own Electron app

Imagine your team owns a desktop reporting application. You have a packaged build and want to understand how its export feature is wired before making a compatibility change. The names and prompts below are illustrative; they are not results from a customer application or a test we performed.

1. Give the investigation a boundary

Prepare a copy of the owned build with synthetic data. A useful initial request would be:

Inspect our local Electron build at /analysis/owned-reporting-app. Map the static report-export path. Do not launch the app, contact network services, or modify its files. Identify relevant artifacts and distinguish evidence from inference.

This makes the question concrete. It also separates analysis of the packaged application from permission to run it. The directory is an example path; use a real absolute path on the host running REA.

2. Inspect the application structure

REA exposes analyze_javascript_application for a local directory or ASAR. A corresponding illustrative MCP input is:

{
  "input_path": "/analysis/owned-reporting-app",
  "format": "directory",
  "integrity_policy": "fail"
}

That input follows the documented static workflow. It does not require a live browser or Electron process. Ask the assistant to retain the artifact identity and limitations alongside its summary so that later questions refer to the same build.

3. Follow the relevant relationships

Ask the assistant to look for the renderer entry point, any preload bridge, and the main-process handler associated with exporting. These are investigation targets, not findings you should assume in advance.

REA’s JavaScript Application Graph represents modules, Electron roles, IPC channels, and relationships between them. Its documentation explicitly distinguishes static inferences from runtime observations. Dynamic or ambiguous relationships may remain unresolved.

A useful follow-up prompt is:

For each proposed connection in the export path, give the artifact location, supporting evidence, and whether the connection is observed, statically inferred, or unknown. Do not fill a missing link with a guess.

For example, a matching channel name could suggest a connection worth checking. It would not, by itself, establish that a particular button caused a particular file write in a real session.

4. Decide whether runtime observation is necessary

Static evidence may answer where the code is organized while leaving a runtime question open. If your team needs to observe execution, approve a separate scenario on a controlled test installation: one build, one synthetic report, one intended export action, and an agreed network policy.

REA provides runtime workflows, but their scope and dependencies vary. Its reconciliation operation consumes existing evidence; it does not itself launch an app or collect a missing observation. Follow the relevant workflow documentation and preserve the distinction between what was captured and what was inferred.

5. Turn the investigation into something useful

Ask for a short report containing:

Your team can then inspect the evidence and write a test against its own application. This closes the gap between an interesting assistant answer and a decision an engineer can review.

How to connect REA to ChatGPT, Codex, or Claude

The reviewed server uses local stdio transport. In practical terms, your MCP client starts a process on a machine that can access the target and required analysis engines.

Start with the documented local setup

The upstream installation entry point is:

npx rea-agents setup

This runs the upstream npm package, not a separate API to Agents release. The installation guide describes selecting clients, reviewing proposed configuration changes, approving them, and restarting the selected agents. Check the current package’s Node requirements and tool prerequisites before running it. If you work from our fork’s source, follow the repository’s instructions and identify the revision you are using.

For native analysis, choose a supported engine that you are entitled to use. Installing MCP access is separate from installing or licensing an analysis provider. REA’s MIT license does not replace third-party tool licenses.

ChatGPT desktop and Codex

OpenAI’s MCP guide documents stdio servers on a Codex host and configuration shared by the ChatGPT desktop app, Codex CLI, and IDE extension. REA includes Codex registration. After setup, verify that the server appears in your chosen local client and that the session can access the intended host files.

That is the relevant local setup path. Hosted ChatGPT web uses plugin-provided remote tools and does not simply read your local Codex configuration. Local-computer access has its own availability and policy constraints; do not assume that a working desktop setup carries into every web session.

Claude Desktop and Claude Code

REA includes setup for both clients. Claude Code documents local stdio servers, and Claude Desktop supports local MCP connections. Follow REA’s client configuration notes, restart the selected app, and check connection status before trying an investigation.

Claude’s remote custom connectors connect from Anthropic’s cloud. They are a separate mechanism from a locally configured server, even when you use the desktop app. A GitHub repository URL is not a connector endpoint.

These are documented connection paths reviewed against the sources above, not a claim that we ran end-to-end REA tests in every assistant.

What a hosted REA service would need

Making this available as a remote service would be a separate engineering project. Beyond an HTTP transport, it would need authenticated users, isolated analysis environments, controlled target ingestion, bounded execution, and a clear policy for storing and deleting evidence. Access to local devices, commercial analysis tools, and private applications would need explicit design.

Our current fork does not ship that hosted service. If you need one, describe the authorized workflow and the environment it must run in. Our MCP authentication overview explains the account and access layer, but authentication alone does not isolate analysis jobs or grant rights to inspect a target.

Keep the permission and data boundaries visible

Use owned test applications, explicitly permitted interoperability work, or an agreed internal audit scope. Check the app or service’s terms and the rights you have to the target. Obtain separate authorization for any execution, network interaction, or device operation required by the investigation.

“Local” describes where REA runs. Tool results sent back to an assistant may be processed by that assistant’s provider. Keep credentials and unrelated personal data out of captures, and review the data policy for the client you use. Treat recovered text and application content as evidence, not instructions for the assistant to obey.

REA makes a useful pattern concrete: a question leads to a tool call, a tool call produces evidence, and the next question becomes more precise. Start with one allowed target and one bounded question. Explore the original project, our fork, and the REA setup overview before choosing your first investigation.