jadx-ai-mcp: an MCP server plugin that lets Claude read your JADX decompilation

What jadx-ai-mcp solves for Android reverse engineers

JADX already decompiles an APK to Java. The awkward part comes after: getting an LLM to reason about that code usually means copying class listings into a chat window, losing the package structure and any ability to follow a call graph. jadx-ai-mcp attacks that gap by exposing the running decompiler through the Model Context Protocol, so the model asks for a class or a method and receives the current decompiled text rather than a stale paste. The README frames it as "live reverse engineering support with LLMs like Claude".

The intended audience is narrow but real: security engineers doing static analysis of Android packages, pentesters, and anyone doing SAST or VAPT work who wants an assistant that can see the same code they see. It is not a general code assistant. It has no meaning outside a JADX session with an APK loaded.

How the plugin and the separate MCP server divide the work

The architecture is two pieces, not one. A JADX plugin lives inside the decompiler process and holds the loaded project: classes, methods, resources, search. A separate MCP server, published as its own repository (jadx-mcp-server) and written in Python, speaks the protocol to the LLM client and forwards requests to the plugin. The README describes the project as a "Fully automated MCP server + JADX plugin built to communicate with LLM through MCP".

That split explains the version requirements printed on the badges: Java 11+ for the plugin, because JADX is a Java application, and Python 3.10+ for the server side. It also explains why the release notes matter in pairs. The v6.3.0 release added remote host support, which suggests the plugin and server do not have to sit on the same machine. The v6.4.0 release is titled "Search Infrastructure Overhauled", so code search inside the decompiled project was reworked at that point. Both changes point at the same design: the server is a thin protocol layer, and the interesting state stays in JADX.

The practical consequence is that the LLM never parses an APK itself. It asks questions, and the plugin answers from an already-built decompilation. That is cheaper and more accurate than feeding a model a smali dump, but it also means the model can only see what JADX has already produced.

Installing the JADX plugin and running a first query

The repository is a Maven project (pom.xml at the top level, sources under src/), and the README points readers at the documentation site at jadx-ai-mcp.readthedocs.io for setup detail. The release assets are the plugin builds, so the usual path is to download the release matching your JADX version and drop it into JADX's plugin directory. The README does not spell out that directory path, so check the Read the Docs pages before guessing.

The server side is a Python package from the companion repository. The README gives no pip command line, so treat the install as documented at the Read the Docs site rather than inventing one. What the badges do confirm is the interpreter floor: Python 3.10+ for the jadx-mcp-server side, and Java 11+ for the plugin.

Once both halves are running, the client configuration is the part you will actually edit. The README does not publish a config snippet, so the example below is a generic MCP client entry rather than a documented one: a command plus arguments that start the Python server. Keep the plugin running inside JADX at the same time, because the server has nothing to talk to otherwise.

{
  "mcpServers": {
    "jadx": {
      "command": "python3",
      "args": ["-m", "jadx_mcp_server"]
    }
  }
}

Confirm the module name and arguments against the Read the Docs install page, since the README itself does not print a client config. After that, open an APK in JADX, start a conversation in your MCP client, and ask for a class by name. If the model returns decompiled Java, the wiring is correct. If it reports no tools, the server process is not reaching the plugin.

Where jadx-ai-mcp breaks down

The README carries a warning, still present as an HTML comment in the source: the project is "still in early stage of development, so expects bugs, crashes and logical erros". That is the maintainers describing their own tool, and it should set expectations. A plugin that lives inside another application's process can take that application down with it.

There is a second, structural limitation. Everything depends on a live JADX GUI session. The related searches include "JADX headless MCP", which suggests people want to run this in CI, but nothing in the README or the release notes describes a headless mode. If your workflow is batch analysis of hundreds of APKs on a build server, this tool is the wrong shape: there is no documented way to drive it without a human opening the decompiler.

Version coupling is the third cost. The plugin is built against JADX internals, and the release history shows four releases between March and August 2026, including a search infrastructure rewrite. Upgrading JADX without a matching plugin release is the obvious way to get a broken session.

jadx-ai-mcp versus scripting JADX directly

The honest alternative is not another MCP server. It is JADX's own command line and its existing script hooks. Running jadx with export flags gives you deterministic Java or smali output on disk, which you can then grep, index or feed to any model in whatever chunks you like. That approach has no live session to keep alive, no Java-to-Python bridge, and no version coupling between two repositories.

The difference in approach is where the intelligence sits. With jadx-ai-mcp, the model queries a running tool and the tool decides what code to return; the loop is interactive and the context stays small. With a plain export, you own the pipeline and the model sees whatever you chose to include. The first is better for exploratory work on a single APK where you want to follow a lead. The second is better for repeatable analysis, diffing two builds, or anything that has to run unattended. Neither replaces the other, and a team doing regular Android triage will probably end up with both.

Maintenance, licensing and the cost of staying current

The repository is not archived, and the last push was on 2026-08-30, with v6.4.1 released on 2026-08-06. The cadence across 2026 is roughly a release every two to three months, which is healthy for a side project but not a stability guarantee. Budget for the upgrade tax: each JADX update is a chance that the plugin's hooks no longer match, and the fix depends on a new release landing.

The licence is Apache-2.0, which permits commercial use and modification, and requires that you keep the licence and notice files and state significant changes. It also includes a patent grant. That is the standard reading of the text; if your organisation ships a modified plugin, have counsel confirm the notice obligations rather than treating this paragraph as advice. One practical point: because the plugin runs inside JADX, any redistribution of a modified build carries the same obligations as redistributing JADX itself.

Editorial conclusion

Adopt jadx-ai-mcp if you already use JADX for Android static analysis and want an LLM to query a live session instead of a pasted code dump; skip it if you need a headless pipeline or a stable API, since the README itself warns of bugs and crashes in this early stage. Verify first that your JADX build matches the plugin release (v6.4.1, pushed 2026-08-30), that Python 3.10+ is available for the separate jadx-mcp-server, and that your client speaks MCP.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. zinja-coder/jadx-ai-mcp on GitHub