jadx-mcp-server: the Python half of a two-part bridge between an LLM client and JADX-GUI

The server does nothing alone: it needs the JADX-AI-MCP plugin and a modified jadx-gui

The project is two tools that work as a pair. The first is JADX-AI-MCP, a plugin for the JADX decompiler that lives in a separate repository, zinja-coder/jadx-ai-mcp. The second is this repository, JADX MCP Server, which the project describes as a standalone Python server. It talks to a modified version of jadx-gui over MCP, the Model Context Protocol, and lets an LLM work with the decompiled Android app context live.

The download link in the README for the plugin points at the releases page of jadx-ai-mcp, not at this repository. This repository itself has no GitHub releases. So if you land here looking for a downloadable build, you will not find one, and you need the plugin repository for the JADX side.

The practical consequence is that installing the Python server is only half of the job. Without the modified JADX-GUI on the other end, an MCP client has a server to call and nothing behind it to answer. Plan for two installations, one for each repository, and check them against each other when something stops working.

Every tool call makes four hops, and a failure at any one looks like a failed tool

The sequence diagram in the README shows how a single request travels. The LLM client invokes an MCP tool on the JADX MCP Server. The server sends an HTTP request to the JADX AI MCP plugin. The plugin hands it to request handlers, which perform the action or gather data from the JADX GUI. The result goes back the same way: handlers craft an HTTP response, the plugin returns it to the server, and the server delivers the MCP tool result to the client.

That means three processes or layers sit between your prompt and the decompiler: the MCP client, the Python server, and the plugin inside JADX-GUI. The link between the server and the plugin is plain HTTP, so the Python side depends on the plugin's HTTP endpoint being reachable.

When a tool returns an error, the client will not necessarily tell you which hop broke. Start by checking whether JADX-GUI is running with the plugin loaded, then whether the server can reach it, and only then suspect the LLM client. The project lists demos for quick analysis, finding vulnerabilities, using multiple AI agents, analysing APK resources, and assistance while debugging an APK in JADX.

Class, method, field and smali tools cover reading, with search paginated for large projects

The README lists the MCP tools the server exposes, and the visible portion is all about reading and navigating decompiled code. fetch_current_class returns the name and full source of the class selected in the GUI, and get_selected_text returns whatever text is currently highlighted. get_all_classes lists every class in the project. get_class_source fetches the full source of a named class, and get_method_by_name fetches a single method's source.

For finding things, search_method_by_name searches for a method across classes, while search_classes_by_keyword finds classes whose source code contains a given keyword and supports pagination. get_methods_of_class and get_fields_of_class list the members of one class, and get_smali_of_class fetches smali.

Pagination on the keyword search is the detail that matters on large APKs. A keyword that appears in hundreds of classes can be paged through instead of returned in one oversized answer. The tool list in the README is cut off after the smali entry, so there may be more tools than the ones named here. Check the live tool listing from your MCP client to see the full set your version exposes.

Kotlin metadata is stripped by default, so pass slim=False when you need the raw dump

Tools that return decompiled source strip Kotlin compiler metadata by default. That covers the @Metadata and @DebugMetadata annotations, which the project says are often 25 to 50 percent of a Kotlin dump. fetch_current_class, get_class_source and get_method_by_name all take slim=True as their default, and passing slim=False returns a raw dump.

The saving is real for an LLM, since that is a large share of tokens that carry no meaning for most analysis questions. It also means the default output is not a byte-for-byte copy of what the decompiler produced. If you are specifically studying how the Kotlin compiler annotated a class, ask for the raw version.

Stripping never changes line numbers. That matters for annotation: get_class_source accepts with_line_numbers=True to number the lines, and add_comment(line=...) uses those numbers to place a comment. Because slimming leaves line numbers alone, a line number you read from the slim output still points at the right place when you add a comment, and the combination of with_line_numbers=True and add_comment(line=...) keeps working in either mode.

A Python 3.10 package with three dependencies and one console script

The server is a Python package. pyproject.toml sets requires-python to >=3.10, uses setuptools >=61.0 as the build backend, and names the project jadx-mcp-server at version 0.1.0. Its description field still holds the template text, Add your description here. Dependencies are fastmcp>=3.0.2, httpx>=0.28.1 and requests>=2.32.3, and requirements.txt repeats the same three lines:

fastmcp>=3.0.2
httpx>=0.28.1
requests>=2.32.3

The module jadx_mcp_server.py is declared as a py-module and the packages under src are found as namespace packages. A comment in the file explains that src/ and src/server/ have no __init__.py and that namespaces are declared explicitly so a setuptools default change cannot silently drop them from the wheel again, with a reference to issue #67. That tells you packaging once went wrong in exactly this way.

A console script entry exposes the main function:

[project.scripts]
jadx_mcp_server = "jadx_mcp_server:main"

The repository also carries a uv.lock and a .python-version file, so uv is the evident route for a reproducible environment, and a test.sh script with a tests/ directory.

Version 0.1.0, no releases and a commented-out early-stage warning set expectations

Several signals say this is young software. The version in pyproject.toml is 0.1.0 and the description is a placeholder. The repository has no GitHub releases, so there is no tag to pin to. And the README source contains a commented-out note saying the project is in an early stage of development and that you should expect bugs, crashes and logical errors. Because it sits inside an HTML comment it does not render on GitHub, but it is still the maintainer's own wording.

The last push was on 2026-10-19. The repository is not archived and is licensed under Apache-2.0. Twenty-three contributors are shown in the README, which suggests more than one person is fixing things, although that count alone says nothing about how often.

The consequence for you is mostly about reproducibility. Without releases, two installs from main at different times can differ. Record the commit you tested against, especially if you build analysis workflows on the exact tool names and parameters, since a young project can still rename them.

The suite includes an APKTool server and a client, and a sample for OpenAI-compatible APIs

This server is described as part of Zin's Reverse Engineering MCP Suite. The suite lists three other components: APKTool-MCP-Server, JAD-AI-MCP-Plugin (the JADX plugin) and ZIN-MCP-Client, each in its own repository under zinja-coder. The APKTool server is the sibling for working with APKs at the Apktool level, while this one is bound to JADX.

The README presents the work as analysing Android APKs with LLMs like Claude, and it mentions finding vulnerabilities and parsing manifests. The examples folder adds one concrete file, examples/openai_compatible_client.py, with its own requirements.txt, which points to a client written for OpenAI-compatible APIs rather than only for Claude Desktop.

One caution applies to every setup of this kind. The tool results contain decompiled source from the APK you are studying. If the LLM client is a hosted service, that code leaves your machine as part of the conversation. For a sensitive sample, check where your client sends its context before you point it at the target.

Editorial conclusion

jadx-mcp-server suits an Android reverse engineer who already uses JADX-GUI and wants an LLM client to read classes, methods and smali from the open project. It is a poor choice if you want a single self-contained install, because it only works together with the separate JADX-AI-MCP plugin, and it still carries a 0.1.0 version and no tagged releases.

Frequently asked questions

Official sources

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