Introducing ARES IDA MCP

Reverse engineering with an AI agent shouldn't mean copy-pasting decompiler output into a chat window. ARES IDA MCP is an unreleased project I've been building to close that gap: a Model Context Protocol bridge that exposes IDA Pro to any MCP-aware client as a structured, task-level tool surface.

This post is a short preview of what it does, why it's shaped the way it is, and what makes it different from a quick "wrap IDAPython in a server" weekend hack.

What it is

ARES IDA MCP is a two-process design:

• An external MCP proxy that speaks stdio or HTTP to your MCP client (Claude Desktop, Claude ​Code, Cursor, Windsurf, VS Code, and friends). The proxy is IDA-free.
• An IDA-side plugin that exposes the actual IDA Pro, IDAPython, Hex-Rays, and optional ida-domain capabilities over a local HTTP endpoint at http://127.0.0.1:13337/mcp.

The proxy and the plugin consume the same declarative tool specs, so the schema your agent sees is exactly the schema the IDA plugin enforces. No drift, no duplication.

Why a bridge instead of a plugin-only server

There are two real constraints that drive the architecture:

1. IDA imports are heavy and version-pinned. You don't want them anywhere near your MCP client process. The proxy runs anywhere Python 3.11+ runs; the IDA imports stay inside IDA where they belong.
2. Agents need a stable surface. Raw IDAPython is a sprawling, version-sensitive API. ARES collapses it into task-level tools — get_function_detail, get_xrefs, decompile, search_database, patch_bytes — with stable JSON envelopes and bounded results.

If Hex-Rays isn't licensed, decompiler tools degrade gracefully with structured unavailable responses instead of crashing the session. Same for ida-domain when it isn't importable in the running IDA.

The tool surface

Broad, but not infinite. Coverage spans:

• Triage — backend status, database summary, address context, segments, entries, imports, exports
• Code understanding — functions, instructions, basic blocks, control-flow and call graphs, xrefs
• Decompilation — Hex-Rays pseudocode, ctree summaries, local variables, decompiler comments, bounded microcode
• Data — strings, names, comments, bytes, items, types, structs, enums, unions
• Search — code, data, immediates, registers, text, byte patterns with wildcards
• Mutation — renames, comments, prototypes, type application — all gated by profile and supporting dry_run
• Patching — byte / integer / string / fill patches, DIF export, patched executable production, file-offset patches, and a planning tool
• Debugger — breakpoints, step in/out/over, registers, threads, modules, memory map, trace events
• Expert escape hatches — run_idapython_snippet, run_domain_query, run_guarded_api_call — only available behind explicit authorization and the expert profile

The recommended agent workflow starts with get_backend_status and get_database_summary, then narrows from there. That's also the system instruction the MCP server advertises to the client.

Profiles, not vibes

Capability is gated by a machine-readable profile rather than ad-hoc checks. Out of the box: readonly, triage, decompiler, type-analysis, mutation, patching, debugger, expert. The default is readonly, so an agent that wandered into your IDB can't rename half your symbols on a hunch.

Mutating tools support dry_run and return before/after results where it's feasible to capture them. Patching has its own dedicated planner — plan_patching_workflow — that reads current IDB patches, file mappings, and output availability and tells the agent what the right next step is (export DIF, produce patched executable, back up the input, save the IDB).

Installation, briefly

One command does the boring part:

ares-ida-mcp --install

It drops the IDA plugin bootstrap into the IDA plugins directory, probes every supported MCP client on the machine, and merges the stdio server entry into each client's own config file — atomically, idempotently, with a one-time .ares-bak backup. Restart IDA, enable Edit → Plugins → ARES IDA MCP, restart your MCP client, and the ares-ida-mcp server is live.

For a workspace-scoped install, the per-client flags are explicit:

ares-ida-mcp --install-client cursor --client-scope workspace --workspace-dir .
ares-ida-mcp --install-client vscode --client-scope workspace --workspace-dir .

If you'd rather hand-edit a config file, ares-ida-mcp --config prints a generic block.

A sample VS Code config

For a project-local install, the resulting .vscode/mcp.json looks like this:

{
  "servers": {
    "ares-ida-mcp": {
      "type": "stdio",
      "command": "/path/to/python",
      "args": ["-m", "ares_ida_mcp"],
      "env": {
        "ARES_IDA_MCP_IDA_RPC": "http://127.0.0.1:13337/mcp"
      }
    }
  }
}

The ARES_IDA_MCP_IDA_RPC variable is the only piece you usually need to think about, and only if you're running IDA on a non-default host or port.

HTTP transport, with the safety on

Stdio is the default. For remote setups there's an HTTP transport that:

• Validates local browser origins
• Supports optional bearer authentication via ARES_IDA_MCP_HTTP_TOKEN
• Refuses accidental unauthenticated non-local binds unless you set ARES_IDA_MCP_ALLOW_INSECURE_REMOTE=1 (don't)

The bundled Docker Compose binds the host port to 127.0.0.1 and won't start without a token:

ARES_IDA_MCP_HTTP_TOKEN="$(openssl rand -hex 32)" docker compose up --build

Tracking API coverage

One thing I care about more than I should: knowing what isn't covered yet. ARES ships a committed snapshot of upstream IDAPython, Hex-Rays, and ida-domain symbols and compares current MCP tool mappings against that source. The output is a generated coverage matrix and a classified backlog of missing symbols, regenerated with:

make api-docs

That backlog is what drives the next batch of tool specs, instead of "whichever endpoint sounded fun this week."

What's next

ARES isn't released yet. The current focus is hardening the mutation and patching paths, expanding debugger coverage, and finishing the prompt library (binary triage, function review, xref explanation, safe patch planning are already in). When it goes public, the install story is the one above — one command, every supported client.

If you spend time in IDA and want an agent that doesn't pretend the decompiler doesn't exist, this is the project I'd point you at. More to share when it ships.