Hex-Rays IDA MCP, the official Model Context Protocol server for IDA

What the server actually exposes to an agent

ida-mcp is the official Hex-Rays IDA MCP Server, and the point of it is to let a coding agent operate an IDA session rather than merely read about one. The usage section puts it plainly: start your agent harness and ask it something like reverse a given binary in IDA. A second example is the GUI integration test, where you open something in the IDA GUI and ask the harness what you have open. That second example is the interesting one, because it implies the agent has two ways in, a headless path and a path that shares the live GUI state, and it gives you a cheap way to check the wiring before you trust the agent with a real binary. The project builds on IDA Nexus, a library that allows several clients to share and operate on IDA databases, and the documentation points developers who want to build their own tools on top of that library. The homepage is the Hex-Rays documentation for MCP, and an announcement blog post describes the project in more detail.

uvx ida-mcp stdio --agent=my-agent

Requirements are narrow, and one of them is about other agents

The requirements list is short and one entry is unusual. You need Git and uv on your path, and you need IDA 9.4 or higher with idalib, plus Python 3.11 or newer. Then there is the recommendation to disable other IDA MCP servers to reduce agent confusion, which tells you something real about how these tools behave. An agent that can see two servers offering similar capabilities will pick between them, and the resulting confusion is not a bug in either server. The package metadata confirms the floor: `requires-python` is set to 3.11 or newer, and the runtime dependencies are `packaging`, `ida-nexus` at 0.13.4 or newer, and `zeromcp` at 1.10.3 or newer. The IDA 9.4 requirement is the one that bites, since the server relies on idalib, the library form of IDA, which is what makes the headless mode possible at all.

Two installation paths, and the agent side is separate

Installation splits cleanly in two. On the IDA side there is a GUI plugin, and on the agent side there is an extension. The automatic route is a single hcli command, which installs the GUI plugin and then interactively offers to install the supported agent plugins. The manual route separates the two halves. The GUI plugin is installed with `uvx ida-hcli plugin install` pointing at the GitHub repository, and the documentation notes that without the GUI plugin the server still works headlessly. The agent side is installed per client, and the list of supported agents is where the ecosystem picture appears: Claude Code, Codex CLI, GitHub Copilot CLI, Pi, oh-my-pi, and a generic path for anything else that can speak the protocol over stdio.

uvx ida-hcli mcp install

The marketplace pattern, and the generic stdio fallback

The agent integrations follow one pattern. For Claude Code, Codex and Copilot you add a Hex-Rays marketplace, then install the plugin from it, and for Claude Code and Copilot there is a plugin update command as well. Pi and oh-my-pi use their own extension commands instead, with Pi installing from a git URL and updating extensions, and oh-my-pi installing from a GitHub reference and running a plugin upgrade. The generic path is the one to understand, because it is the fallback for any client without a marketplace integration. You configure a regular stdio MCP server in your MCP JSON configuration, pointing the command at `uvx` with the package name and the `stdio` subcommand. The configuration includes `--exclude-newer=1s`, and the documentation explains why the version does not need updating each release: `uvx` resolves the latest stable ida-mcp release from PyPI.

{
  "mcpServers": {
    "ida": {
      "command": "uvx",
      "args": [
        "--exclude-newer=1s",
        "ida-mcp",
        "stdio",
        "--agent=my-agent"
      ]
    }
  }
}

Four subcommands: stdio, http, dashboard and logs

The command line surface is small. `stdio` runs the MCP server over standard input and output, which is what an agent harness launches. `http` runs it over Streamable HTTP with a host and a port, and the example binds to 127.0.0.1 on port 8737. `dashboard` inspects the session log and can open it directly. `logs` exports session logs for troubleshooting. The agent label is passed with `--agent` and is described as a human-chosen label, like `claude-code` or `cursor` or a custom name, used to differentiate sessions in the dashboard. The presence of a dashboard and a log export tells you the server keeps a record of what happened in a session, which is the mechanism you would want for reviewing what an agent did to a binary rather than taking its summary on trust.

uvx ida-mcp http --host 127.0.0.1 --port 8737

uvx ida-mcp dashboard --open

uvx ida-mcp logs

A dual-language repository, and why that is not odd here

The repository holds both a Python package and a TypeScript extension, and for an agent integration that is normal rather than accidental. The Python side is the server itself: `ida_mcp/` with the CLI entry point `ida_mcp.cli:main`, the `ida_mcp_plugin.py` file that is the IDA side of the bridge, a `pyproject.toml` built with hatchling that packages only the `ida_mcp` directory into the wheel, and a `uv.lock` for reproducible installs. The TypeScript side is `ida-mcp.ts`, shipped as a pi package and an omp extension, with `ida-plugin.json` describing the plugin, and a single dependency on the Model Context Protocol SDK at 1.29.0 or newer. The npm package is versioned to match the Python one, both at 20261008.0.1, and its keywords name the two extension ecosystems it targets. The TypeScript file is what a JavaScript-based agent harness loads; the Python process is what talks to IDA.

How the release cadence and the licence work

The version scheme is date-based. The three visible releases are v20261008.0.1 on 2026-10-08, v20261003.0.1 on 2026-10-03 and v20260930.0.1 on 2026-09-30, which is a release every few days, and the last push to the repository was on 2026-10-08. That is a fast cadence for a server that sits on top of a commercial tool, and it comes with an operational consequence: the project recommends disabling other IDA MCP servers, which suggests several exist in the same environment. The licence is MIT, declared in both the Python and the JavaScript package metadata, with the licence file listed explicitly in the Python metadata. The repository also has a `docs/` directory, a `scripts/` directory, a `tests/` directory for the Python side, and a `.claude-plugin/` and `.codex-plugin/` directory, which are the marketplace definitions that the plugin installation commands consume. The Python development tooling is pytest, ruff and a type checker, with the test paths set to the tests directory.

Editorial conclusion

Adopt ida-mcp if you already work in IDA and want an agent to read a binary alongside you, especially when several people or agents need to work on the same database, and skip it if you have no IDA licence, since the server is built on top of IDA and idalib rather than being a standalone decompiler. Verify three things before you wire an agent into your analysis loop: that you are on IDA 9.4 or newer with Python 3.11 or newer, because the server requires both; that no other MCP server for IDA is running, since the project recommends disabling them to reduce agent confusion; and whether you want the GUI plugin, since without it the server still works but headlessly, which changes how you verify what the agent did.

Frequently asked questions

Official sources

1. HexRaysSA/ida-mcp on GitHub
2. License: MIT
3. Project website
4. README
5. Releases