ReVa: a Ghidra MCP server that feeds an LLM small tool outputs instead of whole decompilations
MCP server for reverse engineering tasks in Ghidra 👩💻
At a glance
- What is it?
- ReVa is a Ghidra extension that exposes reverse engineering operations over the Model Context Protocol, in assistant mode against a live Ghidra UI or in headless mode for pipelines. Its design bet is that small, schema-guided tool responses keep a language model oriented on large binaries; the same design means you are choosing a Ghidra-only workflow.
- Who is it for?
- Adopt ReVa if your work already lives in Ghidra 12.0 or newer and you want an MCP client such as Claude Code driving analysis on the same project you have open. Do not adopt it if your binaries are analyzed in Binary Ninja or IDA, or if you cannot run Ghidra 12.0+ at all, since the extension will not load.
- Can I use it commercially?
- Yes. Apache-2.0 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 1 day ago.
- What is it written in?
- Mainly Java, 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 problem ReVa targets: LLM context loss on large binaries
Feeding a decompiler listing into a chat window works until the binary is large. ReVa's README frames the problem as context rot and states that the project uses techniques to limit it so that long form reverse engineering tasks stay coherent. The stated mechanism is a tool driven approach: rather than handing the model a large block of decompiled code, ReVa exposes many small tools, each returning what the README calls smaller, critical fragments with reinforcement and links to other relevant information. The intended audience is an engineer who already uses Ghidra and wants a model to drive parts of the analysis, not someone looking for a standalone binary analysis service. The README also lists example prompts that show the intended granularity: explaining the purpose of the __mod_init segment, asking what a function at a given address does, or starting from main and renaming variables as the model goes.
Tool schemas, tolerated input, and the nudge toward human-style exploration
The distinguishing claim in the README is not the MCP transport but how each tool is written. Each tool ships with a schema, and the server tolerates inputs that do not match it, including descriptions that guide the model, and redirects correctable mistakes back to the model instead of failing. Tool output is deliberately partial: the README says responses carry additional context such as the namespace and cross references alongside the decompilation, described as a small nudge to make the model explore the binary the way a human would. That is a real architectural choice with a cost. A model that only sees fragments plus pointers depends on the tool set covering the questions being asked, and the README acknowledges the fallback: the model prioritises information from the tools, but when there is no information it can still answer generic questions from its training. In practice that means a wrong answer is more likely to be a plausible-sounding general answer than a hallucinated address, which is harder to spot.
Two deployment shapes: assistant mode against the UI, headless for pipelines
ReVa runs in two modes, selected through the MCP configuration in the client rather than through a ReVa flag. In assistant mode you start Ghidra with the extension installed, open a project, and connect an MCP client to the server running inside Ghidra. The README states ReVa uses the streamable MCP transport and listens on port 8080 by default, changeable in the Ghidra settings from the project view, and that many clients can connect to the same UI. In headless mode ReVa runs without the Ghidra UI and manages starting Ghidra and projects itself; the README describes headless projects as ephemeral and session-scoped, cleaned up automatically. That cleanup is the detail worth internalising: headless mode is aimed at automation and CI/CD pipelines where you do not need a persistent project, so anything you want to keep has to be exported or committed elsewhere.
Installing the extension and the two plugin checkboxes
ReVa only supports Ghidra 12.0 and above, and the current release notes pair v7.3.1 with Ghidra 12.1.3 and MCP 2.0 support. You can download the release matching your Ghidra version and install it through the Ghidra extension manager, or build from source: clone the repository, export GHIDRA_INSTALL_DIR to your Ghidra path, and run gradle install. Installation is not finished at that point. The README requires activating the extension in two places: in the Project view, open File, select Configure, click the plug-shaped Configure all plugins button, and check ReVa Application Plugin; then in the Code Browser tool do the same and check ReVa Plugin, followed by File and Save Tool so ReVa is enabled by default. Skipping the Code Browser step leaves the plugin installed but inactive in the tool you actually analyze in.
Client wiring for Claude Code and VSCode
The README calls Claude Code the recommended client and gives one command: claude mcp add --scope user --transport http ReVa -- http://localhost:8080/mcp/message. With Ghidra open, /mcp in the chat shows whether the connection is live. To stop permission prompts for every tool call, the README points at /permissions and a rule for mcp__ReVa, which grants the model use of all ReVa tools without asking. That is a meaningful grant: the tool set includes PyGhidra scripting access, so it is worth deciding deliberately rather than accepting it for convenience. VSCode is configured through its built-in MCP client with type http and the same URL in user settings, with the README deferring to the GitHub Copilot documentation for the surrounding steps. ReVa also composes with other MCP servers; the README names the GitHub MCP Server for source lookup and the Kagi MCP Server for web search as examples.
The scripting surface is the sharpest edge in the default configuration
ReVa exposes the PyGhidra scripting environment. The README's own warning is the clearest limitation in the material: if you allow ReVa to listen on a public interface, either enable the API key authentication or disable the scripting tools in the settings. It then states the default: listen on localhost and allow the scripting tools. Those two defaults are safe together and unsafe apart, and the failure mode is silent, because nothing in the client tells you that the endpoint is reachable from elsewhere. The second limitation is scope. The repository description and topics mention Binary Ninja, but the README describes ReVa as a Ghidra extension and the install path is the Ghidra extension manager, so if your analysis pipeline is built on another disassembler, ReVa is not the tool regardless of what the topic list suggests. The third is version coupling: Ghidra 12.0 is a floor, and a release such as v7.3.1 targets a specific Ghidra version, so upgrades on either side need to be planned together.
ReVa compared with a plain decompiler export into a chat session
The obvious alternative is exporting decompiled functions or a whole listing from Ghidra and pasting it into a model, or using a general file-reading MCP server pointed at exported text. The difference is where the context budget goes. A paste gives the model everything at once, and the README's premise is that this degrades on long tasks and large binaries, including entire firmware images. ReVa instead keeps the model on the other side of a request boundary, so each answer costs one tool call and arrives with cross references and namespace information attached. The trade is control: with a paste you decide exactly what the model sees, while with ReVa the tool inventory decides what is reachable, and the README's tolerance for off-schema input plus its fallback to training data means you should treat confident answers about unexamined regions as unverified until a tool call confirms them.
Maintenance, licence, and what to check before committing
ReVa is Apache-2.0, which permits commercial and internal use and modification, with the usual obligations around notices and the absence of any warranty; that is a summary of the licence identifier in the repository metadata, not legal advice, and the LICENSE file governs. Maintenance cost is dominated by version tracking rather than by ReVa itself. Releases arrive on their own cadence (v7.2.1 in April 2026, v7.3.0 in June with diffing, performance and long tasks, v7.3.1 in September with Ghidra 12.1.3 and MCP 2.0 support), and each one is tied to a Ghidra version and an MCP protocol revision, so a Ghidra upgrade, an MCP client upgrade, or both can force a ReVa upgrade at the same time. Building from source adds a gradle step and a GHIDRA_INSTALL_DIR that must point at the matching Ghidra. The first thing to verify on any new install is the settings page in the project view: confirm the listener address, confirm whether API key authentication is on, and confirm whether the scripting tools are enabled, because those three settings decide whether an MCP client on the same machine is a convenience or an open door.
Editorial conclusion
Adopt ReVa if your work already lives in Ghidra 12.0 or newer and you want an MCP client such as Claude Code driving analysis on the same project you have open. Do not adopt it if your binaries are analyzed in Binary Ninja or IDA, or if you cannot run Ghidra 12.0+ at all, since the extension will not load. Before wiring it into anything shared, verify three things in your own install: whether the MCP listener is bound to localhost or a public interface, whether the API key authentication is enabled if it is not, and whether the PyGhidra scripting tools are left on, because the README states those tools are enabled by default alongside a localhost listener.
Community notes