MCP server for Android APK triage. Two backends are supported on the same MCP surface:
- apktool (Java) — the canonical APK disassembler. Produces
a Smali representation of every DEX class plus a decoded
AndroidManifest.xml. Install:apt-get install apktoolor download the jar from https://github.com/iBotPeaches/Apktool/releases. - androguard (Python) — pure-Python APK / DEX / manifest parser. Always installed (the server's hard dep). Faster to import, easier to script; less Smali-friendly than apktool.
The MCP wrappers call whichever backend is available; the
check_apktool tool reports the active backend so the analyst
knows which one fired.
| Tool | What it does |
|---|---|
check_apktool |
Health check — return apktool / androguard / java availability |
parse_apk |
Open the APK, return header info (package, version, min/target SDK, per-file entry list, signature block presence) |
list_dex_classes |
Enumerate classes across every classes*.dex in the APK |
decode_manifest |
Return the decoded AndroidManifest.xml (text) plus the parsed activity / service / receiver / provider / permission lists |
apktool is the gold standard for Smali and manifest
decoding, but it's a Java tool the user has to install. The
parse_apk + list_dex_classes + decode_manifest surface
area is small enough that androguard covers ~90% of the
analyst's needs (header + classes + manifest) without requiring
a JRE. The MCP layer prefers apktool when present and falls
back to androguard cleanly.
pip install -e ./servers/re-apktool # androguard (required)
apt-get install apktool # apktool (optional, java)re-apktool # stdio transport (default for MCP)
python -m re_apktool # equivalentThe original Explore findings called for an APK parser; this
scaffolding lands it so the future Android target run has the
toolchain. The Live Fire Windows-target run uses
re-leak-scan + re-winedbg for the three named products;
re-apktool becomes the workhorse when an Android binary is in
the input.