ReVa: a Ghidra MCP server that feeds an LLM small, targeted reverse engineering tools

What ReVa is for, and who it is actually aimed at

ReVa is a Ghidra extension that runs a Model Context Protocol server inside Ghidra. The intended user is someone who already does reverse engineering in Ghidra and wants a language model to work alongside them on the same project, rather than exporting bytes to some separate service. The README frames the target use cases as long-form work: examining relationships between a main binary and its shared libraries, finding interesting strings, locating encryption and writing a report about it, drawing a class diagram in plantuml syntax, walking from main and renaming variables as it goes, diffing two imported binaries.

The project positions itself against other AI assistants for reverse engineering on one specific axis. The README says ReVa is different because it uses a tool driven approach, giving the LLM a variety of small tools the way your RE environment gives you a set of small tools. That is a design claim, not a benchmark result, and the README offers no numbers to back it. But the claim is concrete enough to evaluate: it means the model is expected to call many narrow functions instead of receiving one giant decompilation dump, and the tool outputs are shaped to reduce context usage. The stated goal is handling large binaries and even entire firmware images, which is where context-window limits normally bite.

The mechanism: schema-tolerant tools, extra context, and context rot

The interesting engineering is in how each tool is built, not in the transport. According to the README, every tool given to the LLM provides a schema but tolerates other input, accepts natural-language descriptions to guide the model, redirects correctable mistakes back to the model instead of failing, and includes extra output that guides the next decision. That is a feedback loop rather than a strict API: a malformed argument can be nudged into shape by the tool itself.

The second mechanism is deliberate context shaping. ReVa reports additional context such as the namespace and cross references alongside the decompilation. The README describes this as a small nudge to make the LLM explore the binary the way a human would, and it explicitly ties the approach to limiting context rot on long tasks. In practice this means the model sees not just a function body but pointers to where that function sits and what calls it, which is exactly the information a human uses to decide where to look next.

Because ReVa is an MCP server rather than a closed assistant, it composes. The README gives two examples: pairing it with the GitHub MCP Server so the model can read source on GitHub, or with the Kagi MCP Server so it can search the web. The model prioritises information from the tools, and the README notes that when the tools have no information it can still answer generic questions from training. That last point is a trade-off worth naming: a model that can fall back on training data can also answer confidently about a binary it never examined.

Installing ReVa as a Ghidra extension and connecting Claude Code

ReVa ships as a Ghidra extension, and the README is explicit that it only supports Ghidra 12.0 and above. The first step is to download the release matching your Ghidra version from the releases page and install it through the Ghidra extension manager. Building from source is the alternative, and the README gives this command, which requires GHIDRA_INSTALL_DIR to point at your Ghidra installation:

export GHIDRA_INSTALL_DIR=/path/to/ghidra
gradle install

After installing, activation happens in two separate places, and skipping either one leaves you with a plugin that does nothing. In the Project view, open File, select Configure, click the Configure all plugins button (the README describes it as looking like a plug), and check ReVa Application Plugin. Then in the Code Browser tool, open File, Configure, Configure all plugins again, and check ReVa Plugin. The README adds one more step that is easy to miss: press File and select Save Tool, which enables ReVa by default in that tool.

With Ghidra running and a project open, ReVa listens on port 8080 by default using the streamable MCP transport. The port is configurable in the Ghidra settings from the project view. For Claude Code, which the README calls the recommended client, registration is a single command:

claude mcp add --scope user --transport http ReVa -- http://localhost:8080/mcp/message

After that, running the claude command with Ghidra open connects to the ReVa MCP server. You can confirm the connection with /mcp inside the Claude Code chat. The README also notes that /permissions can add a rule for mcp__ReVa to stop tool-use prompts, which is a convenience and also a decision about how much autonomy you are handing over.

Headless mode, VSCode, and the scripting exposure you must decide about

VSCode has a built-in MCP client, and the README points to the GitHub Copilot documentation for the general configuration, giving this user-settings snippet as the ReVa-specific part:

{
  "mcp": {
    "servers": {
      "ReVa Assistant": {
        "type": "http",
        "url": "http://localhost:8080/mcp/message"
      }
    }
  }
}

The second operating mode is headless. ReVa can run without the Ghidra UI, which the README recommends for automation and CI/CD pipelines. In that mode ReVa manages starting Ghidra and the projects for you, and those projects are ephemeral, meaning session-scoped and automatically cleaned up. You choose between assistant mode and headless mode through the MCP configuration in your MCP client, not through a separate binary.

The security note in the README deserves more attention than a footnote usually gets. ReVa provides access to the PyGhidra scripting environment. If you let ReVa listen on a public interface, you must either enable API key authentication or disable the scripting tools in the settings. The default configuration listens on localhost and allows the scripting tools. So the safe default and the exposed configuration are not the same thing, and moving ReVa off localhost without reading that paragraph is the mistake this project is most likely to see in the wild.

Where ReVa is the wrong tool

The hard constraint is the Ghidra version. ReVa only supports Ghidra 12.0 and above, so anyone pinned to an older Ghidra for plugin compatibility or for a validated analysis environment cannot use it at all. There is no fallback path described.

The second limitation is structural: ReVa is not a standalone analyzer. It is a Ghidra extension plus an MCP server, so it inherits Ghidra's installation, its project model, and its headless startup behaviour. If your workflow is scripted around a different disassembler, or if you want a CLI that takes a binary path and prints results, ReVa is not that. The pyproject.toml declares the package as Beta, which is consistent with a tool whose release notes still list performance and long-task work as recent themes.

The third issue is the one the README itself raises without resolving: the model can answer from training data when the tools return nothing. On a stripped binary or an unfamiliar architecture, the tool output may be thin, and a model that fills the gap from memory is producing something that looks like analysis. Nothing in the README describes a guard against that. Treat any claim ReVa makes about a function it did not call a tool on as unverified.

How this differs from driving Ghidra scripts yourself

The obvious alternative is Ghidra's own scripting environment. Ghidra ships with a script manager and Python or Java scripts that can walk functions, rename symbols, and export decompilation, and the repository layout here includes a ghidra_scripts/ directory, which suggests ReVa itself relies on that machinery rather than replacing it. The difference in approach is who decides what to run next. A script follows a fixed sequence you wrote in advance; ReVa hands a set of small tools to a model and lets the model choose the next call based on what the previous call returned, including namespace and cross-reference context the README says is attached to decompilation output.

That difference cuts both ways. A script is deterministic, reviewable, and cheap to run a thousand times in CI. An agent choosing its own next step is none of those things, which is precisely why ReVa's headless mode exists: it lets you put the same non-deterministic process into a pipeline. If your task is well-defined and repeatable, a script is the better answer and always will be. ReVa's value shows up on the exploratory work, the CTF problem where you do not yet know what matters, or the long session on a large binary where writing the script would take longer than the analysis.

Maintenance, licensing, and what upgrading costs you

The repository is not archived, and the last push was on 2026-09-08, which is recent. Release cadence is visible in the release list: v7.3.1 on 2026-09-03, v7.3.0 on 2026-06-13, v7.2.1 on 2026-04-07. The v7.3.1 release title mentions Ghidra 12.1.3 and MCP 2.0 support, and v7.3.0 mentions diffing, performance and long tasks. That pattern means version upgrades are not purely additive: a release can move the supported Ghidra version and the MCP protocol version underneath you, so a working setup can break at either layer.

The practical upgrade cost is therefore twofold. You track Ghidra versions, because the extension is built against a specific one, and you track your MCP client, because the transport and protocol version matter. The README's install path (download the release for your Ghidra version) implies matching the two, and the source build path makes the coupling explicit through GHIDRA_INSTALL_DIR.

On licensing: the repository carries Apache-2.0, and pyproject.toml declares license = {text = "Apache-2.0"}. That is a permissive licence with a patent grant and a notice requirement. If you redistribute ReVa or a modified build, read the licence text and the NOTICE handling yourself; this is a description of what the repository states, not legal advice. Note also that Ghidra itself is distributed under its own licence, so your obligations depend on both components, not just this one.

Editorial conclusion

Adopt ReVa if you already work in Ghidra 12.0 or newer and want an MCP client to drive decompilation, renaming and cross-reference exploration on large binaries, or if you need headless Ghidra runs in a CI pipeline. Skip it if you are on an older Ghidra, if you want a standalone binary analysis tool with no Ghidra dependency, or if you cannot accept that enabling the PyGhidra scripting tools on a public interface requires either API key authentication or disabling those tools. Before trusting it on real work, verify three things: that your Ghidra version is supported, that both the ReVa Application Plugin and the ReVa Plugin are checked and the tool is saved, and that your MCP client reaches http://localhost:8080/mcp/message.

Frequently asked questions

Official sources

1. cyberkaida/reverse-engineering-assistant on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases