Loading ToolBench
AI-first Mobile E2E MCP server for Android/iOS/React Native/Flutter
Mobile E2E MCP has well-structured tool definitions with consistent naming (verb_noun pattern: launch_app, install_app, etc.) and complete input schemas across all 9 tools. However, descriptions are generic and lack LLM-optimized guidance on WHEN to use each tool vs. alternatives. Parameter descriptions exist but are minimal (avg ~40 chars vs. baseline 72 chars). No output schemas are documented, forcing LLMs to guess response structure. Error handling is absent, no recovery guidance, retryability classification, or actionable error messages. Security concerns: sessionId/deviceId/appId parameters suggest stateful session management not visible in code; no evidence of permission gates or audit logging. Composition is reasonable (single responsibility per tool), but missing idempotency guarantees and batch variants for common multi-tool patterns.
Classify detected interruption into a specific type (system_dialog, permission_request, etc.)
Collect comprehensive debug evidence including logs, crashes, JS console, and network events
Detect if the current screen has an interruption (dialog, alert, permission request, etc.)
Get the current page context including layout, elements, and interruption state
Install an app artifact on a device or simulator
Launch an app on a device or simulator with optional launch URL
Reset app state using specified strategy (clear_data, reinstall, keychain_reset, etc.)
Resolve an interruption by applying the appropriate action (tap, dismiss, allow, etc.)
No output schemas documented. LLMs cannot infer response structure (fields, types, nesting). Forces guessing on downstream tool chaining and data extraction.
Descriptions are generic and lack LLM-optimized guidance. E.g., 'Detect if the current screen has an interruption' (40 chars) does not explain WHEN to call this vs. classify_interruption, or what constitutes an interruption. Baseline: 194 chars avg.
No error handling or recovery guidance. Tools lack actionable error messages, retryability classification, or next-step hints. E.g., if install_app fails, LLM has no guidance on whether to retry, check device state, or escalate.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | 2026-07-28+ | v2 |
Resume an action that was interrupted by a blocking event
Stateful session management (sessionId, deviceId, appId parameters) suggests server maintains per-request state. MCP spec (2026-07-28) requires stateless request handling with _meta carried in each request. No evidence of per-request _meta or protocol version negotiation.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe reads from destructive writes without explicit hints. E.g., resolve_interruption is marked WRITE but lacks destructiveHint annotation.