apktool-mcp-server: thirteen tools that let an LLM read and patch decoded APK projects

Thirteen tools, all anchored to a decoded apktool project

The server is one Python file, apktool_mcp_server.py, and it exposes thirteen MCP tools. They split into four groups. decode_apk decodes an APK with Apktool, extracting resources and smali code. build_apk builds an APK from a decoded project, and clean_project cleans a project directory to prepare for rebuilding. get_manifest returns the AndroidManifest.xml of a decoded project, and get_apktool_yml returns the apktool.yml information.

For code, list_smali_directories lists the smali directories in a project, list_smali_files lists files in one smali directory with an optional package prefix filter, and get_smali_file returns the content of a class by name. For resources, list_resources accepts an optional resource type filter and get_resource_file returns one file. search_in_file searches for a pattern in files with specified extensions. The two write tools are modify_smali_file and modify_resource_file.

Everything is organized around a project that already exists on disk after decoding. The tools do not take an APK and answer a question in one step. The flow is decode first, then read or edit the project, then build. That is why the sample prompts keep repeating a project name such as dvac: the name is how the server finds the decoded directory. If you skip decode_apk, every other tool has nothing to look at.

Editing stops at smali and resource files, and build_apk is the last tool in the chain

The two write tools change text in a decoded project: modify_smali_file rewrites the content of a specific smali file and modify_resource_file rewrites a specific resource file. After that, build_apk turns the project back into an APK and clean_project resets it for another build.

What the thirteen tools do not include matters as much. Neither the tool descriptions nor the list mention signing a rebuilt APK, installing it on a device, or running it. The README's own sample prompts show the intended edits: insert a log line at the start of onCreate() in MainActivity.smali, add a toast message, replace http links with https in strings.xml, add android:exported=false to activities in the manifest, and add logging statements to methods. One sample patches a validateLogin method in LoginManager.smali so that it returns true.

For the reader, this means a model can change what a decoded project says, but nothing in this server checks that the edit is valid smali or that the rebuilt app behaves. A bad edit surfaces only at build time or at runtime, and the follow-up steps are yours to do outside the server. Treat each modification as something to diff and review, not a verified patch.

Several sample prompts ask for operations that have no matching tool

The sample prompts are grouped as basic code understanding, vulnerability detection, reverse engineering helpers, static analysis, AI code modification, and documentation and metadata. Most map cleanly onto the thirteen tools. Listing smali directories uses list_smali_directories, finding startActivity usage uses search_in_file, and getting a manifest or apktool.yml uses the two get tools.

A few prompts do not map. One asks to compare MainActivity.smali with its previous version and show differences, but no tool stores versions. One asks to extract DEX files from the project for external analysis. Others ask to create a new APKTool project called test-harness, list all decoded APKTool projects in the workspace, and check which APKTool version is currently installed on the server. One asks for all Android devices connected via ADB, and the prompt itself carries the note that this is to be migrated to an ADB MCP Server.

So the prompt list is wider than the tool list. A client model will either improvise with the tools it has, for example searching files instead of diffing versions, or fail the request. If you rely on one of those prompts, check the tool list your client actually shows after connecting, and do not assume the sample prompts describe shipped behavior.

apktool has to work on your PATH before the server is worth starting

The server is a front end for Apktool and does not bundle it. The setup steps begin with downloading and installing apktool from apktool.org/docs/install, then testing that it is configured in the environment variables:

$ apktool -version

Next you download the apktool-mcp-server-<version>.zip from the GitHub releases page and unzip it. The archive contains an apktool-mcp-server folder with apktool_mcp_server.py, requirements.txt, README.md and LICENSE. Then you change into that directory. The README notes that the project uses uv instead of pip for dependencies, and the repository carries a uv.lock file.

Two gaps are visible in the setup text. There is no clone-and-install command; the route is a release zip. And the pyproject.toml declares the package as version 0.1.0 with the description Add your description here, while the releases are tagged V3.0.2, v3.0.1 and v3.0.0. The release number you download is therefore not the number inside pyproject.toml. If apktool is missing or not on PATH, the decode step has nothing to call, so confirm the version command prints before debugging anything in the LLM client.

Claude Desktop connects through uv with an absolute directory path

For Claude Desktop, the server is registered in claude_desktop_config.json. On Linux the README opens it with nano:

nano ~/.config/Claude/claude_desktop_config.json

On Windows the file is %APPDATA%\Claude\claude_desktop_config.json, and on macOS it is ~/Library/Application Support/Claude/claude_desktop_config.json. The README author used a community Debian build of Claude Desktop on Kali Linux. The entry under mcpServers is named apktool-mcp-server and launches uv:

{
    "mcpServers": {
        "apktool-mcp-server": {
            "command": "/<path>/<to>/uv",
            "args": [
                "--directory",
                "</PATH/TO/>apktool-mcp-server/",
                "run",
                "apktool_mcp_server.py"
            ]
        }
    }
}

Two values must be replaced: the path to your uv executable, and the absolute path to the apktool-mcp-server directory. The text says that second one is where you cloned the repository, though the install route above is a zip. Because the command is an absolute path to uv, the entry breaks if uv moves.

The README also recommends a different client for local models: Zin MCP Client, a CLI-based MCP client for STDIO servers that bridges Ollama and MCP servers. Its demo is marked as coming soon.

Python 3.13 is the declared floor, and the dependency list is thin

pyproject.toml sets requires-python to 3.13 or newer. The dependencies are fastmcp at 2.2.0 or newer and a package named logging at 0.4.9.6 or newer. requirements.txt lists just fastmcp and logging with no versions.

The interpreter floor is the main practical constraint. A machine or CI image running Python 3.11 or 3.12 will not satisfy the pyproject declaration, which is easy to hit on a Kali or Debian system whose packaged Python is older. Since uv can manage interpreters, the uv-based launch is the more forgiving path, but the repository does not say that, so check python --version or the uv environment before the first run.

The small dependency set is also a plus for auditing, because the surface that touches your APKs is one Python file plus FastMCP. The cost is that every behavior lives in that single file, and the repository root also holds test.sh, a docs directory, SECURITY.md and CONTRIBUTING.md but no test suite directory. If you plan to depend on specific tool outputs, pin a release and read apktool_mcp_server.py for the exact return shapes.

Three v3 releases in ten months, with an early-stage warning still in the README source

The release line is v3.0.0 (titled Major Update) on 2025-09-12, v3.0.1 on 2026-04-25 and V3.0.2 on 2026-07-02, which is titled Windows Launch Fix. The last push matches that last release date, 2026-07-02, and the repository is not archived. A Windows-specific launch fix in the most recent tag suggests the Windows path was the part that needed repair most recently, so Windows users should read that release's notes first.

The README source also contains a comment saying the project is still in an early stage of development, so bugs, crashes and logical errors are expected. It does not render on the page, so a reader of the rendered GitHub README will not see it, but it is a fair summary of how to treat the thirteen tools. The license is Apache-2.0, and the project says it is part of Zin's reverse engineering MCP suite, alongside JADX-AI-MCP, JADX-MCP-Server and ZIN-MCP-Client.

For teams, the choice is simple. Pin to a specific release zip, keep decoded projects in version control so that every smali edit can be diffed, and use the server for reading and small changes rather than for unattended patching of apps you cannot rebuild and test.

Editorial conclusion

Use it if you already reverse engineer Android apps with Apktool and want an LLM client to read manifests, search smali and make small edits in a decoded project. Skip it if you need a polished release, signing or install steps built into the toolset, or an interpreter older than Python 3.13. Verify apktool works on your PATH and test one decode before trusting any edit.

Frequently asked questions

Official sources

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