Loading ToolBench
MCP server for Android debugging via JDWP, providing tools for device management, screen capture, UI interaction, source resolution, and advanced debugging capabilities
This server defines 27 tools with explicit schemas and descriptions visible in Main.kt. However, critical gaps severely limit production readiness: (1) Parameter descriptions are entirely absent, the schema shows types but no guidance on what each parameter controls or when to use it. (2) Output schemas are not documented anywhere; callers cannot predict response structure. (3) Error handling is minimal, no recovery guidance, no categorization of retryable vs fatal errors. (4) Many parameters lack constraints (enums, ranges, formats), inviting invalid LLM inputs. (5) Tool descriptions are terse (avg ~60 chars) and lack context on when to call each tool vs similar ones (e.g., debug_wait_event vs debug_plan_events). (6) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear WRITE vs READ_ONLY risk labels in the spec. Naming is generally good (verb_noun pattern), but the lack of parameter and output documentation makes this a D-tier server.
Execute an allowlisted Android input action
Abort a running debug plan and resume any paused event it owns
Attach to a debuggable Android app process
Return breakpoint evidence grouped by source line and ordered by hit sequence
Clear breakpoint
Clear a candidate breakpoint group
Clear recorded breakpoint evidence for a debug session
No parameter descriptions. All 27 tools expose parameters (e.g., deviceSerial, sessionId, action, condition) with types but zero guidance on what each controls, valid ranges, or when to use it. LLMs cannot infer intent from names alone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
Detach a debug session
Capture and cache stack frames from the current suspended debug event
Return the current or final report for a debug plan
Return a cached frame snapshot by snapshotId
List candidate breakpoint groups
List breakpoints
Ask a running debug plan to pause at the next handled debug event
Wait for or read debug plan progress events
Read selected variables or fields from the current suspended breakpoint frame
Resume suspended debug event
Run a one-off debug plan inside the MCP server
Set class + line breakpoint
Set multiple candidate breakpoints and optionally continue until required variables are readable
Wait for breakpoint hit
List adb devices
Capture Android screen UI tree, screenshot path, size, and activity
Resolve a JVM/Kotlin class name to candidate source files across modules and source sets
Clear a recorded runtime timeline
Export the recorded runtime timeline as session.json and optional session.html
Return the recorded runtime timeline for a debug session
Output schemas undocumented. No tool specifies what fields it returns, their types, or structure. Callers cannot plan downstream tool chains or extract required data (e.g., does debug_attach return a sessionId? What format?).
No parameter constraints (enums, ranges, formats). Parameters like 'action' (object), 'plan' (object), 'condition' (string) lack validation rules. LLMs will hallucinate invalid values; no guidance on what fields 'action' or 'plan' must contain.
No tool annotations despite explicit WRITE vs READ_ONLY risk labels in spec. Tools like debug_attach, debug_set_breakpoint, debug_resume (WRITE) should declare destructiveHint or idempotentHint to guide agent planning and retry logic.
Minimal error handling. No recovery guidance, no error categorization (retryable vs fatal), no actionable error messages. If debug_attach fails, the LLM has no guidance on whether to retry, call a different tool, or ask the user.