re-apktool
Provides tools for analyzing Android APK files, including parsing headers, listing DEX classes, and decoding AndroidManifest.xml.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@re-apktool decode the AndroidManifest.xml from the APK"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
re-apktool
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.
Tools
Tool | What it does |
| Health check — return apktool / androguard / java availability |
| Open the APK, return header info (package, version, min/target SDK, per-file entry list, signature block presence) |
| Enumerate classes across every |
| Return the decoded |
Related MCP server: APK Security Guard MCP Suite
Why both backends?
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.
Install
pip install -e ./servers/re-apktool # androguard (required)
apt-get install apktool # apktool (optional, java)Run
re-apktool # stdio transport (default for MCP)
python -m re_apktool # equivalentDeferred to a future run
The 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.
Available Tools
5 toolscheck_apktoolA
Return apktool / androguard / java availability.
Active backend is one of "apktool" (apktool jar on PATH
and a JRE), "androguard" (pure-Python fallback), or
"none" (server can't analyse anything).
The MCP layer prefers apktool when both are present because apktool's Smali output is closer to the canonical AOSP form. androguard is the always-on fallback for the header
class enumeration + manifest-decoding tools.
Inputs: no named parameters.
classify_apk_protectionA
Walk the APK + every classes*.dex for known protection patterns.
Uses the vendored data/apkid-signatures.json catalog.
Returns a list of {category, evidence, evidence_offset, evidence_file} records with category-only labels
("apk_packager", "dex_obfuscator", "ssl_pinning",
etc.). The category names describe observable patterns;
no specific commercial product is named.
Args: path: path to the APK max_per_category: per-category match cap (default 50)
Returns::
{
"path": "...",
"matches": [{"category": "...", "evidence": "...",
"evidence_offset": N, "evidence_file": "...",
"match_pattern": "...", "id": "..."}, ...],
"by_category": {"dex-obfuscator": 12, "ssl_pinning": 2, ...},
"truncated": {"per_category": bool}
}The signature table is matched against:
classes.dexstring table (DEX class names + method signatures + string literals);every
lib/*.sofor the native-section + string-literal categories;the manifest's
application/meta-dataelements.
The implementation lives in
servers/re-apktool/src/re_apktool/classify.py.
Inputs: path (required), max_per_category.
decode_manifestA
Decode the APK's AndroidManifest.xml.
Returns the manifest as text (androguard's AXMLPrinter output) plus the parsed activity / service / receiver / provider / permission lists.
When the manifest is binary-only (some closed-source
protectors encrypt it) androguard fails — the analyst
falls back to apktool d directly. The MCP layer
surfaces the error in the response rather than silently
returning a half-decoded manifest.
Inputs: path (required).
list_dex_classesA
Enumerate every class in every classes*.dex in the APK.
Returns one record per class::
{
"fqn": "com.foo.Bar",
"access": "public",
"method_count": N
}plus a per-dex summary. Use this for the "what's actually compiled into this APK" view — class names are the structural fact, not the implementation. Apktool would give a Smali dump; the MCP surface sticks to the typed class graph so the analyst can ask Claude "what classes are in this APK" without dragging the full bytecode into context.
Inputs: path (required).
parse_apkA
Return a structural summary of the APK at path.
Output includes:
package / version / min+target SDK
activities, services, receivers, providers
permissions list
signature scheme (v1 / v2 / v3)
debuggable + allowBackup flags
per-file entry inventory + DEX / native lib / asset counts
Uses androguard for the manifest-backed fields, falls back to a zipfile-only walk for the entry list when androguard is missing.
Inputs: path (required).
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 5 tools
Tools are mostly distinct: check_apktool checks tool availability, classify_apk_protection identifies protection patterns, decode_manifest outputs manifest XML, list_dex_classes enumerates classes, and parse_apk provides a structural summary. Some overlap exists between decode_manifest and parse_apk (both output activity/service lists), but descriptions clarify the different outputs (raw manifest vs. summary).
All tool names follow a consistent verb_noun pattern with snake_case (check_apktool, classify_apk_protection, decode_manifest, list_dex_classes, parse_apk). No mixed conventions or irregular naming.
Five tools is well-scoped for an APK analysis server: checking the backend, classifying protection, decoding the manifest, listing classes, and parsing the overall structure. Each tool earns its place without being redundant or overwhelming.
The set covers core APK analysis tasks (structure, manifest, classes, protection), including signature scheme and entry inventory. Minor gaps exist: no Smali decompilation or resource extraction tools, but the provided tools allow thorough structural and security analysis.
Related MCP Connectors
MCP server for static security analysis of Android source code
MCP server for ScanMalware.com URL scanning, malware detection, and analysis.
MCP server for the Vulners.com API
MCP server: static security scanner for MCP servers, agent skills & plugins. 17 attack patterns.
Related MCP Servers
- AlicenseAqualityDmaintenanceAn MCP server that integrates with Apktool to provide live reverse engineering support for Android applications using Claude and other LLMs through the Model Context Protocol.16709Apache 2.0
- FlicenseNot gradedqualityDmaintenanceProvides a one-stop automated solution for Android APK security analysis by integrating tools like JEB, JADX, APKTOOL, FlowDroid, and MobSF into unified MCP standard API interfaces.11-
- AlicenseNot gradedqualityDmaintenanceA Python MCP server that decompiles Android APK/XAPK/JAR/AAR files and extracts HTTP APIs used by the app.8Apache 2.0
- AlicenseAqualityDmaintenanceAn MCP server that enables AI assistants to analyze Android APK and iOS IPA files for security issues through natural language conversation, including permission auditing, secret detection, and SDK enumeration.1218 npm8MIT