Loading ToolBench
Headless jadx decompiler + MCP server (single-process, Streamable HTTP) for reverse engineering
Strong tool set with clear naming (verb_noun pattern: load_apk, get_class_source, search_string_constants) and comprehensive descriptions (avg 180 chars, well above 10-char minimum). All 16 tools have descriptions explaining WHAT, WHEN, and context. Input schemas present with type declarations and parameter descriptions. However, output schemas are not documented in the provided source, critical for LLM planning. Some parameter descriptions lack format/constraint details (e.g., 'path' in load_apk has no validation guidance). Error handling guidance is absent from descriptions. Tool composition is excellent (single responsibility, clear chaining via class_name/method_name). No security issues detected (no secrets in params). Pagination implemented correctly (offset/limit pattern on 5+ tools with documented defaults).
Clear in-heap caches (disk index retained for reuse).
Which APK is loaded, with class count and index build status.
Classes that contain a given string literal (exact by default; set contains=true for substring).
Paginated list of all class FQNs (including inner classes).
Decompiled Java source of one class (disk-cache hit → instant; otherwise decompiles on demand).
Fields of a class: name and type.
Locate method(s) by name in a class and return signature(s) + a best-effort decompiled snippet of each. Pass descriptor to scope to one overload.
Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., what does get_class_source return? Is it a string, object with metadata, paginated result?). Critical for tool chaining.
Parameter descriptions lack format/constraint details. 'path' in load_apk has no guidance on absolute vs relative, file existence validation, or supported formats. 'class_name' accepts 'FQN or raw class name' but no examples or disambiguation rules.
Error handling guidance absent. Descriptions do not explain what to do if APK fails to load, class not found, or index still building. LLMs have no recovery path.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | <=2025-11-25 | v2 |
Methods of a class: name, descriptor (for overload disambiguation), return type, args.
Packages with their class counts (sorted), paginated — a cheap structural overview.
Smali (bytecode) of one class.
Android string resources from res/values/strings.xml (name → value), paginated.
Classes that reference a class (out-of-heap SQLite graph). Empty + 'index building' note means retry.
Callers of a method (merged across overloads unless descriptor is given).
Background index build progress (state/percent/symbols/edges/strings). search_in_code and string tools are fully populated once state=ready.
Load (or switch to) an APK/DEX/AAB/XAPK/APKM/JAR for analysis. Resident + lazy: classes decompile on demand, and a background SQLite index (symbols/xref + FTS code search) builds afterward. Call this first; poll index_status for search readiness.
Substring search over const-string literals → matching strings + their classes. The primary locator on obfuscated apps (names are meaningless; string literals are not).
Pagination defaults not consistently documented. get_all_classes specifies 'default 200, max 2000' but get_package_tree and get_strings lack explicit defaults. Inconsistency forces LLMs to guess.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) not present. Spec 2026-07-28 recommends these for agent planning. load_apk and clear_cache should be marked destructive/write; read tools should be marked readOnly.