This tool reverse engineers APKs using Jadx and Apktool, and allows searching for strings or reading files in the output.
Three tools with basic schemas and descriptions, but significant gaps in parameter documentation and output structure. Tool names lack clear verb-noun patterns (reverseAPK vs reverse_apk convention). Descriptions are present but generic (10-60 chars, below 194-char baseline). No parameter descriptions for critical inputs like 'file' and 'filePath'. Output schemas are undocumented, LLMs cannot predict return structure. Error handling exists but lacks recovery guidance. No tool annotations (readOnlyHint/destructiveHint). searchInReversedCode attempts streaming via sendProgress, but this is non-standard and not part of MCP spec.
Read a file from the reversed APK output by relative path
Reverse engineer an APK using Jadx and APKTool
Search for specific strings in the reversed APK output
Tool names do not follow verb_noun convention. 'reverseAPK' should be 'reverse_apk' or 'reverse_application'. CamelCase names reduce LLM parsing clarity.
Parameter 'file' in reverseAPK lacks description. LLM cannot infer expected format (absolute path? relative? .apk extension required?). Baseline: 100% of A+ tools have param descriptions.
No output schema documented. LLMs cannot predict return structure (text content only, no structured fields). Baseline: 100% of A+ tools document return types.
Error messages lack recovery guidance. 'No reversed directory found' does not tell LLM to call reverseAPK first. Baseline: errors must guide next action.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | <=2025-11-25 | v2 |
reverseAPK is destructive (writes to disk, runs external commands) but has no destructiveHint annotation. Agents cannot reason about side effects.