Loading ToolBench
Android memory debugging and manipulation server via HTTP bridge, exposing memory scanning, breakpoint management, syscall tracing, and process introspection tools
LuckyStar MCP provides 40 tools with consistent naming (android_* prefix) and complete input schemas. However, descriptions are terse (avg ~60 chars, well below the 194-char baseline), lack context about when to use each tool, and omit dependency hints. Parameter descriptions are present but minimal. Output schemas are not documented. Error handling guidance is absent. The tool set is well-structured for a specialized domain (Android memory debugging), but falls short of production-grade LLM-optimization standards.
List all active breakpoints.
Update breakpoint record fields.
Remove breakpoints.
Set breakpoints at specified addresses.
Diagnose bridge reachability; normal tools connect automatically and do not require this first.
Read cycle counter value.
Start cycle counter tracing.
Stop cycle counter tracing.
Descriptions are uniformly terse (avg ~60 chars vs 194-char baseline). Most lack context about when to use the tool, prerequisites, or what it returns. E.g., 'Read the current target process bound inside the Android HTTP bridge' does not explain why an LLM would call this or what the response structure is.
Output schemas are not documented. Tools return structured data (e.g., scan results, memory regions, breakpoint lists), but the response format is not visible in the tool definitions. LLMs cannot plan downstream calls or extract fields without knowing the response structure.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | <=2025-11-25 | v2 |
Read ARM64 environment parameters for the current target process.
Dump a module name or a half-open address range such as 0x5000-0x6000.
Read memory at an address or module segment.
List memory regions and modules for the current target process.
Refine results. Value modes need value, range also needs range_max, and history modes need neither.
Read one result page; value_type must match the active scan (string for string scans).
Start a scan. equal/greater/less/pointer/string need value; range also needs range_max; unknown needs neither.
Close a memory viewer.
Open a memory viewer at an address.
Read from an open memory viewer.
Write to an open memory viewer.
Write memory at an address.
Resolve a module segment start or end address from the current target process.
Scan for pointers to a target address.
Read pointer scan results.
Add a saved address to the watched list.
List all saved addresses.
Lock a saved address to a specific value.
Remove a saved address from the watched list.
Unlock a saved address.
Update a saved address value.
Scan for a signature pattern in memory.
Read signature scan results.
Read syscall trace log.
Start syscall tracing for the current target process.
Stop syscall tracing.
Resolve a package name to PID and make that process the current target.
Read the current target process bound inside the Android HTTP bridge.
Resolve a package name to PID without changing the current target.
Bind all scan, viewer, and breakpoint operations to a known PID.
Configure the Android HTTP bridge connection parameters.
Discover Android HTTP bridges on the local network.
No error handling guidance. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do next. E.g., if android_target_attach_package fails because the package is not installed, the LLM has no recovery path.
Parameter descriptions lack constraint details. E.g., 'Scan mode' does not explain which modes require a value parameter, which require range_max, or which require neither. Undocumented dependencies force LLMs to guess or fail.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The Risk field in the spec indicates WRITE vs READ_ONLY, but this is not exposed in the MCP tool definitions. LLMs cannot distinguish safe reads from destructive writes without explicit annotations.