apktool-mcp-server: Driving apktool from an MCP Client
A MCP Server for APK Tool (Part of Android Reverse Engineering MCP Suites)
At a glance
- What is it?
- The project wraps apktool's decode, build and file-editing steps behind thirteen MCP tools so an LLM client can read and patch a decoded APK project. It is a thin orchestration layer, and the README itself warns it is early-stage software.
- Who is it for?
- Adopt it if you already run apktool by hand and want an LLM client to read manifests, smali and resources without you pasting files into a chat window. Do not adopt it as a sandbox or as a substitute for apktool itself: the README carries an inline warning that the project is in an early stage of development and that bugs, crashes and logical errors should be expected, and the tools include write operations such as modify_smali_file and modify_resource_file.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 76 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What apktool-mcp-server actually removes from the loop
apktool already does the hard part: it decodes an APK into smali, resources and a manifest. The friction is in the loop around it. You run apktool d, open the right file, copy a class into a chat window, ask a question, copy the answer back, edit the smali, run apktool b, and repeat. apktool-mcp-server puts each of those steps behind an MCP tool so the model can call them itself. The README frames the intended flow as decompile, context-aware code review, then AI recommendations, in real time. The audience is narrow and identifiable: Android reverse engineers and VAPT testers who already know what smali is, and who want an LLM to hold the project context instead of a browser tab. The README's sample prompts are aimed at that reader, asking for declared permissions in a manifest, hardcoded URLs across .xml and .smali files, or exported activities and receivers. This is not a tool for someone who has never run apktool.
Thirteen tools, one working directory
The architecture is deliberately thin. The README lists the available MCP tools and they divide into three groups. Decode and rebuild: decode_apk, build_apk, clean_project. Read: get_manifest, get_apktool_yml, list_smali_directories, list_smali_files, get_smali_file, list_resources, get_resource_file, search_in_file. Write: modify_smali_file and modify_resource_file. There is no index, no database and no parser of its own. The server reads and writes files inside a decoded apktool project directory, and the model supplies the path and the class name, for example com.vulnerable.component.MainActivity. That design keeps the tool surface small, which matters because every tool is a thing the model can get wrong. It also means the quality of any answer depends on the smali and XML that apktool produced, not on anything this project computes. The README's own sample prompts assume a workspace of named projects such as dvac, so the mental model is a directory of decoded APKs that the server is pointed at.
Getting it running: download, uv, apktool on PATH
The README's setup path is a release zip, not a git clone. Download the apktool-mcp-server-<version>.zip from the releases page, unzip it, and cd into the resulting directory, which contains apktool_mcp_server.py, requirements.txt, README.md and LICENSE. apktool itself is a separate prerequisite, installed from apktool.org, and the README asks you to confirm it with apktool -version before going further. That check is the one step worth doing carefully, because the server shells out to apktool rather than reimplementing it. For dependencies the project uses uv rather than pip. The README gives curl -LsSf https://astral.sh/uv/install.sh | sh to install uv, then an optional uv venv plus source .venv/bin/activate (or .venv\Scripts\activate on Windows), then an optional uv pip install httpx fastmcp. Note the word optional in both places: the README treats the virtual environment and the explicit dependency install as fallbacks for when dependency errors appear, which suggests the release zip is meant to run without that step. The README also points to ZIN-MCP-Client and describes running against a local model through Ollama as the recommended configuration. The truncated README does not show the exact client configuration block, so the client-side wiring is the part you will have to read on the repository itself.
The write tools are the part to think about twice
modify_smali_file and modify_resource_file do exactly what their names say, and the sample prompts show how far that goes: patch validateLogin in LoginManager.smali to always return true, add android:exported="false" to every activity in the manifest, replace http:// links with https:// in strings.xml. Those are edits to files on disk, driven by a model, inside a working project. Nothing in the supplied material describes a dry-run mode, a diff preview, a backup of the original file, or a confirmation step before a write. The README's inline HTML comment is blunt about the maturity level: the project is still in an early stage of development, so expect bugs, crashes and logical errors. Combine that with a tool that rewrites smali and the practical conclusion is to point it at a decoded copy you do not mind losing, and to keep the original APK. clean_project and build_apk sit on the same surface, so a mistaken call can also discard or rebuild a project you were mid-way through analyzing.
Where the MCP layer stops and apktool begins
It is worth being precise about what this project does not do, because the name oversells it. It does not disassemble DEX, decode resources or assemble smali. apktool does all of that, and the README links to apktool's own repository and installation docs. It does not decompile to Java. The unit of work here is smali, which is apktool's assembly-like output, and the sample prompts that ask for a class by name are asking for a .smali file. If your review process is built around readable Java, this is the wrong layer. The sibling projects in the same suite, JADX-AI-MCP and JADX-MCP-Server, point at jadx instead, and the README lists them as alternatives rather than as complements. The other stated gap is ADB: the README lists a prompt for connected Android devices and marks it as to be migrated to an ADB MCP Server, so device interaction is not part of this server today.
A real alternative, and the difference that matters
jadx is the obvious comparison, and the README's own suite makes it concrete. jadx decompiles Dalvik bytecode to Java source and can export a Gradle project; apktool decodes to smali and resources and can rebuild an APK. The difference shows up in what you can do afterwards. If the goal is to read logic and reason about it, Java from jadx is easier for a model and for you. If the goal is to change behaviour and reassemble a working APK, smali plus apktool's build step is the path, and that is the path this server exposes through modify_smali_file and build_apk. The two are not interchangeable, and choosing between them is a question about whether you intend to produce a modified binary or just an explanation. A second alternative is simply not using MCP at all: run apktool d, open the files in an editor, and use a chat window for questions. That costs you the automated file reads, but it also removes a model's ability to write to your project directory.
Licence, maintenance and what the release history shows
The project is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant, with the usual requirements around retaining notices and stating changes. That matters here because the tool modifies third-party APKs; the licence covers the server, not the APK you point it at, and redistributing a patched APK raises questions the licence does not answer. Do not read any of this as legal advice. On maintenance, the supplied material shows three releases: v3.0.0 in September 2025, v3.0.1 in April 2026, and V3.0.2 in July 2026, the last titled Windows Launch Fix. The pattern is a major version followed by two targeted fixes months apart, with the most recent one addressing a platform-specific startup problem rather than a feature. The README's own note about early-stage development is consistent with that cadence. The practical cost of upgrading is low in principle, since the surface is a single Python entry point and two dependencies, but the release notes are the only record of what changed, and the truncated README does not document a versioning or deprecation policy for the tool names.
Editorial conclusion
Adopt it if you already run apktool by hand and want an LLM client to read manifests, smali and resources without you pasting files into a chat window. Do not adopt it as a sandbox or as a substitute for apktool itself: the README carries an inline warning that the project is in an early stage of development and that bugs, crashes and logical errors should be expected, and the tools include write operations such as modify_smali_file and modify_resource_file. Before trusting it, verify that apktool -version resolves on your PATH, then decode one throwaway APK and diff the smali output against a manual apktool d run.
Community notes