jadx-mcp-server: an MCP bridge between Claude and a patched jadx-gui

The problem: an LLM that cannot see the decompiler's state

Reverse engineering an APK with an LLM usually means copying decompiled Java into a chat window, pasting a manifest, then pasting more when the answer is wrong. The model never sees the file tree, so every question costs another round of manual copying, and nothing it produces can be checked against the actual class it came from. jadx-mcp-server exists to remove that copying step. It is a standalone Python process that speaks MCP (Model Context Protocol) to an LLM client and, on the other side, talks to a modified build of jadx-gui distributed as the jadx-ai-mcp plugin. The README describes the goal plainly: it "lets LLMs communicate with the decompiled Android app context live." The audience is narrow and specific: mobile application security testers, VAPT consultants and Android reverse engineers who already use jadx-gui interactively and want an assistant that can read the same session they are looking at. It is not a decompiler. It does not parse DEX files, and it does not replace jadx. It is a transport layer between two programs that must both be running.

Architecture: two processes, one plugin, one MCP client

The repository layout makes the split clear. The top level holds jadx_mcp_server.py, a src/ directory, pyproject.toml, requirements.txt and uv.lock; the runtime dependencies are fastmcp, httpx and requests. fastmcp is the MCP framework that exposes tools to the client, httpx and requests are HTTP clients, which tells you the server reaches the plugin over HTTP rather than by embedding jadx. The companion repository, zinja-coder/jadx-ai-mcp, is where the patched jadx-gui lives, and the README points at its releases page for downloads. So the data flow is: Claude or another MCP-capable client sends a tool call to the Python server, the server forwards it over HTTP to the running patched jadx-gui, the plugin executes it against the loaded APK, and the result travels back the same way. That design has a direct consequence worth stating. The Python process holds no APK state of its own, so if jadx-gui is closed, or the plugin is not loaded, or the port is wrong, every tool call fails. The README does not document the plugin's endpoint, port or handshake, which is the first thing you will have to find in the jadx-ai-mcp repository before anything works.

Installing jadx-mcp-server and making a first call

The README gives no pip or uv install command, so the practical route is from source. The project declares Python 3.10 or newer in pyproject.toml and pins three dependencies: fastmcp>=3.0.2, httpx>=0.28.1 and requests>=2.32.3. Those same three lines are what requirements.txt contains, so installing that file into a virtual environment reproduces the declared runtime set:

pip install -r requirements.txt

The presence of uv.lock suggests uv is the maintainer's tool of choice, but the README does not print a uv command, so the requirements file is the only install step the repository actually spells out. The package also declares a console entry point, jadx_mcp_server, mapped to the main function in jadx_mcp_server.py, so after installation you can start the server through that script. Note that the repository ships a test.sh and a tests/ directory; the README does not describe what test.sh does, so treat it as something to read before running rather than a documented check.

Before starting the Python side, the patched jadx-gui must be running with an APK loaded and the plugin active. The README directs users to the jadx-ai-mcp releases page for that download. Once both are up, register the server with your MCP client. The exact registration format belongs to the client, not to this project, and the README does not print one. What you need to supply is the command that launches jadx_mcp_server plus any environment variables the plugin connection requires; the README does not list those variables, so read the jadx-ai-mcp documentation for the endpoint details. A first useful call is a manifest read, because it is cheap and immediately verifiable against what jadx-gui shows on screen. If the call returns the package name and permissions, the chain is wired correctly. If it times out, the plugin is not listening.

Where it breaks, and when it is the wrong tool

The most obvious failure mode is a missing companion. jadx-mcp-server has no fallback to stock jadx, and the README is explicit that it interacts with a modified version of jadx-gui. Install the Python package alone and you have an MCP server whose tools all fail on connection. A second limitation is lifecycle coupling: because the server proxies to a GUI process, the analysis session is tied to a desktop application. That rules out the headless batch use case. If you want to decompile a hundred APKs on a build machine and have an LLM triage them, this architecture does not give you that, and the README does not describe a headless mode. The README also carries a comment stating the project is "still in early stage of development" and warns to expect bugs, crashes and logical errors. Version 0.1.0 in pyproject.toml is consistent with that. There are no retrieved releases for this repository, so there is no changelog to tell you what changed between commits. Finally, the pyproject description field still reads "Add your description here", a small sign of how much polish the packaging has received. None of this makes the tool bad; it makes it a tool for people who are comfortable reading the companion repository's source when the README stops.

How this differs from driving jadx from a script

The obvious alternative is to skip MCP entirely and script jadx's command line, or use jadx-gui's own search and export features, feeding results to the model yourself. The difference is where the state lives. A scripted approach is stateless per invocation: you decompile, dump to disk, and the model reads files. jadx-mcp-server keeps the model attached to a live session, so a follow-up question can reference the class the analyst currently has open. That is a real advantage for interactive triage and a real disadvantage for reproducibility, since a session is not a file you can commit. Another comparison point in the same family is Apktool-MCP style setups, which operate on a decoded resource tree rather than on jadx's decompiled Java view. Those suit manifest and resource work; this project suits reading decompiled code and cross-referencing it. The choice is about which representation of the APK your questions are about, not about which tool is stronger. If your work is mostly smali and resources, an Apktool-based bridge may fit better. If it is Java-level logic, this one is aimed at you.

Licence and the cost of keeping up

The repository is Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notices intact and state significant changes. That matters here because the tool is meant to run inside consulting workflows where client code passes through it. Apache-2.0 also includes a patent grant, which is more permissive than a bare MIT in that respect. This is a description of the licence text, not legal advice; if you redistribute a modified build, read the LICENSE file in the repository. The upgrade cost is the part the README does not address. There is no retrieved release history, no changelog and no stated compatibility matrix between jadx-mcp-server versions and jadx-ai-mcp plugin versions. Because the two halves are separate repositories with separate release pages, a version skew between them is the most likely source of breakage after an upgrade. The last push to this repository was on 2026-08-31. Pin the plugin build you tested against, and treat any plugin update as a change that needs re-verification rather than a drop-in.

Editorial conclusion

Adopt it if you already run the patched jadx-gui from zinja-coder/jadx-ai-mcp and want an LLM to query a live decompiled session rather than pasted snippets; skip it if you only have stock jadx, since the server has nothing to talk to, or if you need headless CI analysis, which the README does not describe. Before relying on it, confirm that the plugin's HTTP endpoint is reachable from the Python process, that your Python is 3.10 or newer, and that your MCP client can register a stdio server. The project is Apache-2.0, so redistribution is permitted, but the README carries no versioning or migration policy.

Frequently asked questions

Official sources

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