IDA MCP with REA

REA adapts an IDA MCP server you already run. It does not install IDA, it does not upgrade it, and it does not accept every upstream catalog. The failure that matters is attached mode against upstream 2.0.0: the tool names changed, and REA stops instead of guessing a mapping.

The other native engine is Ghidra MCP with REA. If the REA server itself is missing, start at REA setup not working.

Two lifecycle modes

You pick one mode in the upstream MCP JSON, point REA_IDA_MCP_CONFIG at that file, and select ida once. No provider starts during discovery. Per docs/ida-provider.md.

Mode	What it connects to	What REA checks	Known working
Attached	An IDA GUI that is already open	Legacy GUI tool names, including `get_metadata`, `list_functions`, and `decompile_function`	Upstream 1.4.0
Headless	The database supervisor API: `idb_open`, `idb_list`, `idb_close`	The live tool catalog, not a version string	Builds that actually serve those three tools

Official wording for who installs IDA, verbatim:

Install and configure your selected engine and upstream MCP using their instructions. REA does not install, upgrade, activate, or license them, and does not bundle another IDA server.

The headless profile is defined by that supervisor API, not by an upstream version string. Early builds can report themselves as 2.0.0 and still lack idb_close. REA reads the live catalog. A version number is not a compatibility guarantee. Per the official docs.

Existing IDA Pro profiles use upstream ida-pro-mcp. An optional native bridge for IDA Pro and IDA Free is a separate attached registration, covered below.

Why upstream 2.0.0 fails closed

Attached mode needs the legacy GUI tool names. Upstream 2.0.0 renamed those tools. REA has not established an equivalent attached-mode lifecycle and ownership contract for the new catalog. Per the official docs:

The attached profile requires the legacy GUI tool names; upstream 2.0.0 renamed those tools, and REA has not established an equivalent attached-mode lifecycle and ownership contract for that catalog. It therefore fails closed with the missing tool names in the error diagnostics.

Fail closed means the error lists the missing tool names. REA does not silently fall back, invent a mapping, or keep going with a partial tool set. A page that says "IDA works with REA" without this sentence is describing 1.4.0 attached, or headless, and not saying which.

Headless is a different question. It can be a 2.0.0-era server if, and only if, tools/list includes idb_open, idb_list, and idb_close. The version string is not the test.

Input binary and hash verification

Open the original input binary in REA. Do not point it at an .idb or an .i64 database. The file's SHA-256 must match the input hash IDA recorded. REA checks the attached identity and image base around each analysis request. A mismatch or a target switch fails with recovery guidance. Per the official docs.

If the error is an identity or hash mismatch, the first check is whether REA was given the database file instead of the binary IDA opened. The original input has to stay readable by REA for the whole session.

Universal Mach-O rejection

Attached profiles refuse a universal Mach-O at admission, and that includes native mode. Every slice shares the recorded whole-file hash, so REA cannot tell which slice the GUI loaded. Per the official docs.

The workaround in the same paragraph: open a thin file extracted with lipo -thin in both IDA and REA, or use headless mode, which analyzes the selected slice.

Native bridge security defaults

IDA Pro and IDA Free can use the separate ida-free-mcp plugin through an explicit attached registration. REA does not install IDA, build the plugin, activate a license, or launch the GUI. Per the official docs.

The native MCP 1.1.2 release binds 0.0.0.0 and has no listen-address setting. REA's loopback URL restriction does not change that listener. Restrict inbound access with the host firewall, or use an upstream build that binds only to loopback, before you start the plugin. Per the official docs.

Native MCP 1.1.2 can jump to the previously focused pseudocode tab when you switch functions. Upstream 1.1.3, or a source build that includes the navigation correction, focuses the disassembly view before jumping to the requested entry. This REA profile does not repair stale GUI output. The official doc says verification has to include two different functions before anyone claims function switching is reliable, and that upstream 1.1.3 was not the build used in the initial Linux check.

The registration's optional timeoutMs defaults to 300000 milliseconds for upstream requests. An upstream SDK request that hits that limit returns provider_timeout with the operation and the budget that was actually applied. Per the official docs.

Verification scope

Per docs/ida-provider.md, the initial real workflows are:

stdio, legacy Windows GUI profile, and a Windows x64 headless supervisor with IDA 9.3
the headless workflow on macOS arm64 with IDA Professional 9.1 (build 9.1.250226), against upstream commit c133c3853faa111a9b00ee615c013b720d0c4acd

Linux headless engine operation, other IDA releases, other architectures, and modern attached GUI tools need their own real workflows before support is claimed. A real IDA HTTP-supervisor workflow is unverified. Per the official docs.

rea doctor --provider ida --json validates the registration without starting IDA. It leaves runtime compatibility and target binding for analysis. Per the official docs. This site has not run the IDA verifier.

What's not covered

Whole-symbol inventory, mutation, debugging, arbitrary Python forwarding, and requested GUI navigation are outside this adapter. Complete body ranges, typed reference edges, CFG, referenced data, source locals, comment kinds, and database revision are unavailable. An empty unsupported dossier facet means unknown, not observed absence. Per the official docs.

Hopper is not an attached-to-whatever-is-open engine. The Hopper launcher REA uses creates a document from an executable. Its command-line interface does not attach to an already-open document. Per the official installation guide.

REA does not switch providers when IDA fails. A timeout, an installation failure, or a permission denial needs the recovery that error reports. Per docs/mcp-contracts.md.

Ghidra MCP with REA — startup budgets, string and p-code limits, and the prompt-injection boundary on tool results.
REA setup not working — registration and provider checks before the first IDA call.

Last verified: 2026-10-18 · REA 6.6.0 (tag rea-agents-6.6.0) · docs unchanged at 6.7.0 (tag rea-agents-6.7.0) · fields quoted per the official docs/ida-provider.md.