JADX-AI-MCP: a JADX plugin that lets an LLM client read the APK you have open in the decompiler

The plugin answers HTTP and a separate Python server speaks MCP

The design is a relay with five hops. An LLM client invokes an MCP tool on the JADX MCP Server. That server sends an HTTP request to the JADX AI MCP plugin running inside JADX. The plugin hands the request to a request handler, the handler performs the action or gathers data from the JADX GUI, and the answer travels back as an HTTP response and finally as an MCP tool result.

The consequence is that the Java plugin in this repository never speaks MCP itself. It is the HTTP endpoint inside the decompiler. Anything that expects to connect an MCP client straight to this plugin will find nothing to talk to, because the protocol translation lives in the other half.

Two repositories have to be installed together

The README states that the system is a combination of two tools: JADX-AI-MCP, which is this plugin, and the JADX MCP Server, which is a standalone Python server living in the zinja-coder/jadx-mcp-server repository. The server is described as the piece that interacts with the plugin through MCP and lets LLMs communicate with the decompiled Android app context live.

There is no single package that gives you both. You set up the plugin inside JADX, then run the Python server that your LLM client connects to. No install command is quoted in this article, so follow the Read The Docs site at jadx-ai-mcp.readthedocs.io, and look at TROUBLESHOOTING.md in the repository if the two halves cannot find each other.

The tool list maps onto what you would click in JADX

The MCP tools mirror manual decompiler work. fetch_current_class returns the class name and full source of the selected class, and get_selected_text returns whatever text is highlighted. get_all_classes lists classes in the project, get_class_source returns the full source of one class, and get_method_by_name fetches a single method. search_method_by_name searches methods across classes, while search_classes_by_keyword finds classes whose source contains a keyword and supports pagination.

For structure there are get_methods_of_class, get_fields_of_class and get_smali_of_class. Two manifest oriented tools, get_main_activity_class and get_main_application_classes_code, start from AndroidManifest.xml: the first fetches the main activity, the second fetches the main application classes based on the package name defined there. The listed tools continue past these, but the pagination on keyword search is the detail that matters for large APKs, since a keyword like http can match a great many classes.

A running JADX GUI with the APK loaded is part of the setup

In the sequence diagram the request handlers act on the JADX GUI. They perform actions and gather data there, and the GUI replies with the result. That puts a running JADX window, with your APK already opened, at the centre of every call.

Tools such as fetch_current_class and get_selected_text make this obvious, because their answer depends on what you currently have selected on screen. If you changed the selection while the model was working, the next answer changes too. It also means this plugin is not a batch analysis service. The architecture described in this repository starts from the GUI, so check the docs before planning an unattended pipeline.

Decompiled source goes to whichever model your client uses

Tool results travel back to the LLM client as MCP tool results. Whatever class source, smali or manifest data you ask for is therefore handed to the model behind that client. The project advertises use with Claude, and its demos include running with your favorite LLM client and using multiple AI agents, so the model choice is yours.

That matters for confidential APKs. A client-side privacy policy decides what happens to the code, not this plugin. If the application belongs to a customer or is under embargo, confirm the data handling terms of the model provider before connecting it. The Apache-2.0 license covers the plugin, not what the model does with the text it receives.

Claimed vulnerabilities are model output until you confirm them

The project description promises to uncover vulnerabilities, analyze an APK and reverse engineer it effortlessly, and one of the demo videos is titled Quickly find vulnerabilities. Other demos cover quick analysis, analyzing APK resources, and acting as an AI assistant while debugging an APK in JADX.

Treat those as workflows, not guarantees. The plugin supplies source and structure; the model supplies the judgment, and a model can misread obfuscated code or invent a finding. Open the cited class in JADX and read it yourself before you write something into a report. The value here is speed in navigation and summarization, with you still responsible for the conclusion.

Releases are recent, and the 6.4.0 search rewrite is the change to know

The latest release is v6.5.0, published on 2026-10-19, which is also the date of the last push. Before it came V6.4.1 on 2026-08-06 and v6.4.0 on 2026-05-28, titled Search Infrastructure Overhauled. If you read older guides that describe keyword search behavior, they may predate that overhaul.

The code is Java built with Maven, as the pom.xml shows, and the default branch is named jadx-ai rather than main. The repository also ships SECURITY.md, CONTRIBUTING.md and a mkdocs.yml for the documentation site. The plugin belongs to the Zin MCP Suite, which also lists APKTool-MCP-Server, JADX-MCP-Server and ZIN-MCP-Client as sibling projects, so you can find companions without leaving the same author's work.

Editorial conclusion

JADX-AI-MCP suits Android reverse engineers who already work in the JADX GUI and want an LLM client to read the same session through MCP tools. It is the wrong choice for pipelines without a GUI, and you should check what the model sees and verify every claimed vulnerability yourself.

Frequently asked questions

Official sources

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