ida-mcp-rs: driving IDA Pro from an AI agent without the GUI
Headless IDA Pro MCP Server
At a glance
- What is it?
- blacktop/ida-mcp-rs wraps IDA Pro's idalib interface in an MCP server so an agent can open, disassemble and decompile binaries headlessly. It is a thin, useful bridge with a hard dependency on a paid IDA licence and a version-matched install.
- Who is it for?
- Adopt ida-mcp-rs if you already hold an IDA Pro 9.4 licence, work on macOS or Linux, and want an agent to script function listing, cross-references and Hex-Rays decompilation without opening the GUI. Do not adopt it if you have no IDA licence, rely on a version older than 9.2, or need a tool that works without IDA's own loaders.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap between IDA's GUI and an agent's tool loop
IDA Pro is normally a desktop application. You open a database, click through functions, and read the decompiler in a pane. An AI agent cannot do any of that. It needs a callable interface with named operations and structured returns, and it needs the analysis to happen somewhere other than a window a human is watching. ida-mcp-rs fills that gap by exposing IDA's headless library (idalib) over the Model Context Protocol. The README describes the project as a headless IDA Pro MCP server for AI-powered reverse engineering, and the topic list confirms the stack: idalib, idapro, mcp, rust. The intended user is someone who already owns IDA Pro 9.4 and a valid licence, and who wants an agent to triage a binary before a human opens it. It is not a disassembler. Every capability it offers is IDA's, routed through a Rust binary that speaks MCP.
How the server talks to idalib and to the agent
The binary links against IDA's shared libraries at runtime rather than bundling them. The README's runtime requirements table lists libida.dylib on macOS, libida.so on Linux and ida.dll on Windows, with fallback configuration for each: DYLD_LIBRARY_PATH, IDADIR (read by the launcher) or LD_LIBRARY_PATH, and on Windows either placing the executable in the IDA directory or setting IDADIR and adding that directory to PATH. Standard install paths are auto-detected through baked RPATHs. That design keeps the release archive small and avoids redistributing Hex-Rays code, but it means the server is only as portable as the host's IDA install. On the agent side, the server registers under a name you choose, and the README shows the same command shape for Claude Code, Codex CLI and Gemini CLI, plus a JSON block for Cursor using .cursor/mcp.json with a command entry of ida-mcp. The data flow is: agent sends an MCP tool call, the Rust server translates it into an idalib operation, IDA performs the work against the open database, and the result comes back as structured output the agent can read.
Opening a database is fast because analysis is a separate step
The usage example is explicit that open_idb returns quickly and analysis runs separately. Three tools work immediately without analysis: list_functions, disasm_by_name and strings. That split matters on large binaries. The README recommends running analyze_funcs with background: true for cross-references and decompilation on big inputs, which returns a task_id that you poll with task_status. The example task identifier has the form analyze-<random>. Decompilation is gated twice: it requires Hex-Rays and completed analysis, and the example call is decompile(address: "0x100000f00"). There is also a discovery tool, tool_catalog, shown queried with the string "find callers", which suggests the tool surface is larger than the README enumerates. That is worth noting: the README demonstrates a handful of tools but does not publish a complete list, so the catalog is the place to look rather than the documentation.
Where the database lands, and why the hash check exists
By default a raw input is loaded with IDA's normal loader and saved to <input>.i64. The idb_out parameter redirects that database elsewhere, which the README frames as useful for read-only input directories. The reuse rule is the interesting part: an existing output is reused only when IDA's recorded input SHA-256 matches the current file. The rebuild: true flag can overwrite a database only when its hash or recorded input path proves it belongs to the input. This is a deliberate guard against the classic mistake of pointing a tool at a path that has since been replaced by a different binary, then reading stale analysis as if it described the new file. It is a small design decision with real consequences for anyone scripting bulk analysis over a directory of samples. The README text on headerless blobs is truncated mid-sentence at the point where it says the same open_idb tool accepts something further, so the exact parameter for headerless input cannot be confirmed from the supplied material.
The version lock is the constraint that will bite first
ida-mcp versions mirror IDA Pro versions: v9.4.x for IDA 9.4, v9.3.x for IDA 9.3, v9.2.x for IDA 9.2. A mismatch is detected at startup with a clear error message, which is better than silent failure but still means you cannot simply install the latest release against an older IDA. The distribution channels differ in which version they carry. Homebrew's blacktop/tap/ida-mcp tracks the latest, and Scoop and the Nix user repository publish the latest as well. For older IDA releases you are directed to the matching GitHub Release or, on Apple Silicon only, a versioned cask such as blacktop/tap/ida-mcp@9.3 or ida-mcp@9.2. The practical consequence is that a team standardised on IDA 9.2 on Intel macOS has a narrower path than one on 9.4: the versioned casks are described as Apple Silicon, so the remaining option is a direct release download. This is the clearest case where the project is the wrong tool: if your IDA version is older than 9.2, or you cannot install a matching release, there is no supported route in the documentation.
Getting it running: three commands and two environment variables
On macOS with a standard installation in /Applications, the setup is one command: claude mcp add ida -- ida-mcp. If the loader reports Library not loaded: @rpath/libida.dylib, the fix given is claude mcp add ida -e DYLD_LIBRARY_PATH='/path/to/IDA.app/Contents/MacOS' -- ida-mcp. Auto-detected macOS paths are the MacOS directories inside IDA Professional 9.4.app, IDA Home 9.4.app and IDA Essential 9.4.app. On Linux the installer defaults to ~/ida-pro-9.4 and the launcher script auto-detects it, so the same single command works; for other locations you pass IDADIR, as in claude mcp add ida -e IDADIR='/path/to/ida' -- ida-mcp. The documented resolution order is $IDADIR, then ~/ida-pro-9.4, then /opt/ida-pro-9.4 and other RUNPATH fallbacks. Windows has three options: copy ida-mcp.exe into the IDA directory and register that full path, install through Scoop which auto-detects IDA and sets IDADIR, or set IDADIR and PATH manually with the PowerShell snippet in the README, then restart the terminal. For Cursor, the equivalent is the mcpServers block in .cursor/mcp.json. The Nix route is a single nix shell invocation against github:blacktop/nur#ida-mcp with the nix-command and flakes experimental features enabled.
What you are actually adopting, and the licence question
The project itself is MIT licensed, which covers the Rust server code. It does not and cannot cover IDA Pro or idalib. The README lists IDA Pro 9.4 with a valid license as a prerequisite, and the runtime linking model means the binary is inert without IDA's shared libraries present. Decompilation additionally requires Hex-Rays, which is a separate paid component in IDA's product line. So the effective cost of adoption is the IDA licence you already hold or must buy, plus the maintenance cost of keeping the ida-mcp release tag aligned with your IDA version on every upgrade. The release cadence in the supplied data shows three releases between mid-July and late August 2026, which suggests the tags move when IDA does. None of this is legal advice; if you redistribute the binary or bundle it into a product, the interaction between the MIT licence on the wrapper and Hex-Rays' terms on the linked library is a question for your own counsel, not for this README.
How this differs from running IDA's own scripting interface
The obvious alternative is IDAPython, or IDA's headless command-line mode, driven by a script you write yourself. That approach has no MCP layer, no tool schema, and no agent-facing protocol; you get IDA's full API and you own all the glue. ida-mcp-rs trades that flexibility for a fixed, discoverable tool surface that any MCP-capable agent can call without custom integration work. The cost of the trade is that you can only do what the server exposes. The README shows list_functions, disasm_by_name, strings, open_idb, analyze_funcs, task_status, decompile and tool_catalog, and it does not document the full set, so an analyst who needs a specific IDA API call that has no corresponding tool has to go back to scripting. A second alternative, using a disassembler that is not IDA, removes the licence dependency entirely but also removes Hex-Rays output, which for many reverse engineering tasks is the reason to use IDA in the first place. The honest framing is that this project is a convenience layer over an existing paid tool, not a replacement for it.
Editorial conclusion
Adopt ida-mcp-rs if you already hold an IDA Pro 9.4 licence, work on macOS or Linux, and want an agent to script function listing, cross-references and Hex-Rays decompilation without opening the GUI. Do not adopt it if you have no IDA licence, rely on a version older than 9.2, or need a tool that works without IDA's own loaders. Before wiring it into a workflow, verify three things: that your installed IDA version matches the ida-mcp release tag, that the runtime library resolves (libida.dylib via DYLD_LIBRARY_PATH, libida.so via IDADIR, ida.dll via PATH on Windows), and that your Hex-Rays licence covers the decompile tool you intend to call.
Community notes