apktool-mcp-server: driving Apktool from an LLM over MCP

What apktool-mcp-server actually takes off your plate

Apktool already does the hard part: it decodes an APK into smali, resources and an apktool.yml manifest of the build. What it does not do is let a language model ask questions about that output. apktool-mcp-server sits between the two. It is a Model Context Protocol server, so an MCP-capable client such as Claude can call named tools instead of you running apktool d, then grepping through directories by hand.

The README frames the workflow as "Decompile → Context-Aware Code Review → AI Recommendations". That is a fair description of the loop, with one caveat: the recommendations come from the model, not from the server. The server supplies file contents and write access. It does not ship a rule engine, a vulnerability database or a scoring system. If you want findings, you still have to ask for them and judge the answer.

The intended user is someone doing Android reverse engineering who already understands smali and AndroidManifest.xml well enough to spot a wrong answer. The sample prompts in the README lean that way: listing smali files under a package prefix, checking exported activities, searching for PendingIntent.getActivity. These are tasks a human analyst would otherwise do with grep and an editor.

The tool surface: decode, read, modify, rebuild

The server exposes a fixed set of MCP tools. On the Apktool side there is decode_apk(), build_apk() and clean_project(). On the project side there is get_manifest(), get_apktool_yml(), list_smali_directories(), list_smali_files(), get_smali_file(), modify_smali_file(), list_resources(), get_resource_file(), modify_resource_file() and search_in_file().

The data flow is file-based rather than in-memory. decode_apk() runs Apktool and leaves a decoded project on disk. Every later read or write operates on that directory tree, which is why the README talks about "the dvac project" by name. The model never holds the APK; it holds paths and file contents.

That design has a consequence worth stating plainly. modify_smali_file() and modify_resource_file() are write operations on your working copy, and the README does not document an undo, a diff step or a backup. clean_project() is described as preparing a directory for rebuilding, not as restoring original content. If a model writes a bad patch, your recovery path is re-decoding from the original APK. Keep it.

search_in_file() takes a pattern and a set of file extensions, which is the closest thing here to a query language. There is no index and no symbol resolution; you are searching decoded text.

Installing apktool-mcp-server and running a first decode

Apktool is a prerequisite, not a bundled dependency. The README points to the Apktool install documentation and then asks you to confirm the binary is reachable. If this command fails, nothing else in the server works.

apktool -version

The project ships as a release archive rather than a pip package. The README says to download apktool-mcp-server-<version>.zip from the releases page and unzip it, which yields apktool_mcp_server.py, requirements.txt, README.md and LICENSE.

unzip apktool-mcp-server-<version>.zip
cd apktool-mcp-server

Dependency management is uv, not pip. The README installs uv with the official script, then optionally creates a virtual environment and installs the two runtime dependencies. Note the mismatch: the README installs httpx and fastmcp, while requirements.txt lists fastmcp and logging, and pyproject.toml lists fastmcp and logging as well. Treat fastmcp as the dependency that matters.

curl -LsSf https://astral.sh/uv/install.sh | sh
uv venv
source .venv/bin/activate
uv pip install httpx fastmcp

After that, register the server with an MCP client and point it at an APK. The README's own example asks the model to decode an APK into a project named dvac, then read the manifest. Your first real check should be get_apktool_yml(), because that file records the version and original APK metadata the rebuild will use. If the manifest comes back empty or the project name is wrong, the decode did not land where the server expects.

# Prerequisite check before any MCP call
apktool -version

Where this breaks: wrong tool, thin docs, version drift

The most common failure is treating this as a security product. It is not. Nothing in the tool list performs taint analysis, control-flow reconstruction or signature matching. The README's vulnerability prompts are suggestions for what to ask a model, and the quality of the answer depends entirely on the model and on how much smali you feed it. A model reading a single smali file will miss interprocedural behaviour; a model asked to review an entire decoded APK will hit context limits long before it finishes.

Second, the rebuild path is fragile in a way the README does not address. build_apk() depends on Apktool's own round-trip fidelity, which varies with obfuscation, resource shrinking and framework version. The README does not document rollback, does not describe how to handle build failures, and does not state which Apktool versions are supported. If you modify resources and the rebuild fails, you are debugging Apktool, not this server.

Third, packaging is inconsistent. The README's install steps and the repository's declared dependencies do not line up: pyproject.toml sets requires-python to >=3.13 while the README badge says Python 3.10+, and the version field in pyproject.toml reads 0.1.0 against a latest release of V3.0.2. None of that stops the server from running, but it means you should not treat any single file as the source of truth for versions. Check the release you downloaded.

Finally, the README carries a commented-out note that the project is in an early stage and to expect bugs, crashes and logical errors. It is a comment rather than rendered text, but it is in the repository, and the release history (V3.0.0, v3.0.1, V3.0.2, the last on 2026-07-02) is consistent with a project still settling.

apktool-mcp-server against JADX-based and Frida-based MCP servers

The README places this project inside a suite that also includes JADX-AI-MCP, JADX-MCP-Server and ZIN-MCP-Client. The meaningful alternative is the JADX route, and the difference is the decompiler, not the protocol.

Apktool produces smali, which is a readable assembly-like representation of Dalvik bytecode, plus decoded resources. It is faithful to the bytecode and it can rebuild. JADX produces Java source, which is far easier for a model to reason about and much closer to how a human reads an app. The trade-off is that Java output is a reconstruction: inlined code, synthetic methods and obfuscated names all degrade it, and JADX is not built around the modify-and-rebuild loop that Apktool supports.

So the choice is roughly: pick apktool-mcp-server when you intend to patch something and rebuild it, or when smali-level fidelity matters. Pick a JADX-based server when you only need to read and understand logic, and you want the model working on Java rather than smali. Running both is reasonable; they answer different questions about the same APK.

Frida-based MCP servers occupy a different position again, because they attach to a running process. That is dynamic analysis. apktool-mcp-server is static: it never runs the app. If your question is what the code does at runtime under a specific input, no amount of smali reading replaces instrumentation.

Licence, maintenance and what an upgrade costs you

The project is Apache-2.0, the same licence family as Apktool itself. That is permissive: you can use it commercially, modify it and redistribute it, provided you keep the licence and notices intact and state significant changes. It also includes an explicit patent grant. This is not legal advice, and if you plan to redistribute a modified server inside a product, read the LICENSE file in the archive rather than relying on the badge.

The practical licence question is not the server but the APKs. Apache-2.0 governs the code here; it says nothing about your right to decompile or modify a given application. That is a separate legal and contractual matter, and the README does not address it.

Maintenance looks current. The last push was on 2026-07-02, the same day as the V3.0.2 release, which the release notes describe as a Windows launch fix. The repository is not archived. There is no changelog in the top-level file listing, so upgrade cost is mostly about Apktool compatibility: a new Apktool release can change decoded output, and this server reads that output by path and structure. Upgrading the server without upgrading Apktool, or the reverse, is the combination most likely to produce a confusing failure. Pin both, and re-run a decode after either changes.

Editorial conclusion

Adopt apktool-mcp-server if you already use Apktool by hand and want an LLM client to drive decode, smali reads and small patches without you retyping paths. Skip it if you need a scanner that finds vulnerabilities on its own, or if you cannot install Apktool and put apktool on PATH first, because decode_apk() and build_apk() are only wrappers around that binary. Before trusting it on real work, run apktool -version, decode one APK, call get_manifest() and get_apktool_yml() to confirm the project layout matches what the server expects, and keep the original APK so you can re-decode after a bad modify_smali_file() call.

Frequently asked questions

Official sources

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