jadx-mcp-server: an MCP bridge between an LLM and a running jadx-gui

The gap this fills: decompiled context is stuck inside a GUI

Decompiling an Android APK with jadx-gui produces a large, browsable tree of Java, resources and a manifest. Getting any of that into an LLM normally means selecting text, copying it, and pasting it into a chat window. That breaks down quickly: the interesting parts of an app are spread across many classes, and the reasoning you want the model to do depends on seeing several of them at once. jadx-mcp-server exists to remove the copy step. The README describes it as a standalone Python server that interacts with a modified version of jadx-gui and lets LLMs communicate with the decompiled Android app context live. The audience is narrow and specific: application security testers, mobile reverse engineers, and VAPT practitioners who already work inside jadx-gui and want an assistant that can read what they are reading. It is not a general static analysis tool and it does not decompile anything itself.

Two repositories, one plugin, and where the code actually runs

The architecture is a chain, and every link has to be present. At the bottom is jadx-gui, but not the stock build: the README points to jadx-ai-mcp, described as a modified version of jadx-gui. That fork carries a plugin. The plugin is what exposes the decompiled app context. In the middle sits jadx-mcp-server, a standalone Python process that speaks MCP and talks to that plugin. At the top is an MCP client, with Claude Desktop named in the README as the example. The data flow is therefore: MCP client sends a request, the Python server forwards it to the plugin inside the running jadx-gui, the plugin reads from the loaded APK, and the result travels back. The important consequence is that jadx-gui must be running with the target APK loaded. This is a live-context design, not a batch design. Nothing in the supplied material describes a headless mode or a way to point the server at an APK file directly, so treat the running GUI as a hard requirement rather than an implementation detail.

Install order matters more than the individual commands

The README does not reproduce a full command sequence, so what follows is the order the material implies rather than a transcript. First, satisfy the version floors the badges state: Java 11 or newer and Python 3.10 or newer. Second, obtain the modified jadx-gui from the jadx-ai-mcp repository, which is also where the README sends you for downloads. Third, install and start jadx-mcp-server as a Python process. Fourth, register that process as an MCP server in your client; the README's stated target is a local LLM client such as Claude Desktop, which means an entry in that client's MCP server configuration pointing at the Python server. Fifth, launch the modified jadx-gui and load the APK you want to analyse. The failure mode to expect is ordering: if the server starts before the GUI has an APK loaded, or if the plugin is not active in the GUI, the server has nothing to relay. Note also that the repository's own release list is empty. The downloads the README links to live under the jadx-ai-mcp repository, not this one, so version pinning happens on the plugin side.

The early-stage warning is the most important line in the README

The README carries an HTML comment stating the project is still in an early stage of development and that you should expect bugs, crashes, and logical errors. That comment is easy to miss because it does not render, but it should shape how you use the tool. A crash in this server is not a crash in jadx; it is a broken link in the chain, and the LLM on the other end will simply receive nothing useful. Worse is the logical-error case. When a decompiler and a language model are chained, an incorrect answer about a class or method is hard to distinguish from a correct one, because the model presents both with the same confidence. There is no validation layer described in the material. The other structural limitation is scope: this is Android APK analysis only, mediated entirely by jadx's decompilation. It is the wrong tool for native binaries, for iOS, or for anything you would rather process in a scripted pipeline rather than an interactive GUI session.

What it is not: the difference from driving jadx from a script

The obvious alternative is jadx's own command-line interface, which the upstream project provides and which many teams already wrap in shell or Python scripts. The difference in approach is fundamental. A CLI invocation is stateless: you export decompiled sources to a directory, then grep, parse, or feed those files to whatever you like, including an LLM. That works headlessly, fits in CI, and produces artefacts you can diff between runs. jadx-mcp-server is the opposite: stateful, interactive, and dependent on a GUI process holding an APK in memory. You gain the ability to ask about the code you are currently looking at without exporting anything, and you lose reproducibility and automation. Neither is strictly better. If your goal is a repeatable scan that runs on a build server, the CLI route is the one that survives contact with a pipeline. If your goal is exploratory work where a human is already clicking through classes in jadx-gui, the MCP route removes real friction. Choosing wrongly here means either fighting a GUI dependency you did not need, or doing manual exports you could have avoided.

Licence, maintenance and the version-matching tax

The server is Apache-2.0, which is permissive and includes an express patent grant, so embedding it in internal tooling is uncomplicated. The complication is not legal, it is operational. Two repositories have to stay in step: the Python server here and the jadx-ai-mcp plugin and modified jadx-gui over there. The README's badges track both repositories' contributors and the plugin's downloads, which reflects that reality. A mismatch between the MCP protocol version the server speaks and what the plugin expects is the kind of breakage that shows up as a silent empty response rather than a clear error. Because this repository has no releases of its own, you are tracking the main branch, and the last push date is the only freshness signal available. Budget for the upgrade cost as a paired operation: update the plugin and the server together, and re-verify the connection after each change. Note that this is a description of the licence terms, not legal advice; if you redistribute, read the Apache-2.0 text yourself.

Who should wire this up, and the three things to check first

This is worth adopting if you do interactive Android reverse engineering in jadx-gui and you want an LLM reading the same decompiled context you are. The value is proportional to how much time you currently spend copying class bodies into a chat window. It is not worth adopting if you need unattended analysis, if you cannot run a GUI on the analysis machine, or if you require a tagged release you can pin in a lockfile. Before committing, verify three things. First, that the jadx-ai-mcp plugin release you download is the modified jadx-gui build, not stock jadx, since the plugin is what the server talks to. Second, that the MCP client you intend to use can register a local stdio server, because Claude Desktop is the only client the README names. Third, that the server and plugin versions are compatible, since the repository's empty release list means there is no version matrix to consult and the only way to know is to start both and confirm the connection returns real data from a loaded APK.

Editorial conclusion

Adopt jadx-mcp-server if you already use jadx-gui for Android reverse engineering and want an LLM to read decompiled context without you copy-pasting it. Do not adopt it if you need a headless pipeline, a stable API, or a tool with published releases you can pin. Before wiring it into anything, confirm that the jadx-ai-mcp plugin release you download matches the server version, that your jadx-gui is the modified build the plugin expects, and that Python 3.10+ and Java 11+ are present on the machine running the GUI.

Official sources

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