Summary

The escape hatch is the main tool.

The inventory and search tools cover the routine questions, but `run_ida_command` is what makes this open-ended: anything expressible in IDAPython is reachable. That also sets the security frame — scripts the model writes execute inside your IDA session with your privileges over the binary, and the loopback-only bind is the containment. Keep it that way unless you have a reason not to.

What it is

Two pieces that work together. A plugin, `ida_remote_server.py`, runs an HTTP server inside IDA Pro on `127.0.0.1:9045`; an MCP server in front of it turns those operations into tools. IDA stays open with your binary loaded, and the assistant works against that live session.

What you get

`run_ida_command` — execute an IDAPython script by absolute path, optionally writing its output to a file
`get_functions`, `get_exports`, `get_strings` — inventory of the loaded binary
`get_disassembly` — disassembly for an address range, or a set number of instructions from a start address
`search_immediate_value` — find immediate operands, with a radix and an optional address range
`search_text` — find text in the binary, case-sensitive or not, within an address range
`search_byte_sequence` — find byte patterns such as `90 90 90`
The plugin's own HTTP API underneath, including `/api/imports` and three script-execution endpoints, if you want to script it outside MCP

Requirements

IDA Pro 8.3 or later with a binary already open, Node.js 18 or later, and the plugin file copied into IDA's plugins directory — the path is documented for Windows, macOS and Linux. The MCP half is built from source with `npm install` and `npm run build`; the repository's package name is `ida-server`. By default the plugin binds only to `127.0.0.1`; exposing it to a network means editing `DEFAULT_HOST` in the plugin, with the consequences that implies.

Setup effort

Build from source — clone the repository and build it, then point your client at the binary