Loading ToolBench
Android MCP server providing tools for device control, messaging, file access, and accessibility automation
PocketMCP presents 11 tools with schemas present and descriptions provided, but quality is inconsistent. Most tools have adequate naming (verb-first convention), moderate-length descriptions (averaging 150-200 chars), and structured input schemas. However, critical gaps emerge: (1) several tools lack parameter descriptions or have vague ones (e.g., 'action' in flashlight/global_action lacks enum constraint documentation); (2) output schemas are completely undocumented, no tool specifies what fields/types it returns, violating pattern:response-shaper; (3) the 'human_command' tool is a severe composition violation, it bundles natural language routing, message sending, WhatsApp-specific logic, and verification into one megafunction, violating pattern:tool (single responsibility); (4) error handling is generic ('resultError()') with no recovery guidance or actionable error messages; (5) critical security issue: 'human_command' and 'http_request' expose high-risk operations without confirmation/dry-run patterns. The tool definitions are visible and registered explicitly via McpToolHandler interface, so no inference penalty applies. None of the 11 tools document their output structure.
Retrieve precise, real-time diagnostic information about the Android device. Includes battery level, charging status, OS version, active network interface, memory usage, and IP address. Use this to check device status before resource-heavy operations.
Control flashlight (on, off, toggle) and read known state.
Best available last-known location from device providers.
Run Android global actions such as home, back, recents, and lock screen.
Perform an outbound HTTP request from the phone.
Ultimate fast-path for natural language execution. Ingests raw user instructions (e.g., 'text John on whatsapp hello') and autonomously routes, executes, and verifies the entire flow in one turn. Use this to process broad human requests instantly without step-by-step reasoning.
human_command tool violates single-responsibility principle. It combines natural language intent parsing, contact resolution, messaging (WhatsApp, text, general), routing, execution, and verification in one tool. This creates ambiguous semantics and prevents LLM composition.
No output schemas documented for any of the 11 tools. The rubric baseline expects 100% of A+ tools to have documented return types. LLMs cannot plan downstream operations or extract typed fields without knowing what structure each tool returns.
Enum constraints not enforced in schema. 'action' parameter in flashlight and global_action lists valid values only in descriptions ('on, off, toggle, status'). Should be declared as enum in schema to make them machine-parseable and prevent hallucinated values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 56 | - | v1 |
Open or close an app by package name, app name, or natural language voice command. Supports commands like 'open youtube', 'launch google', 'start instagram'.
List launchable installed apps, with optional search query.
Make a phone call to a specific number or contact
Read a file from allowed storage paths.
Search contacts by display name and return phone numbers.
Parameter descriptions are sparse or absent. 'max_bytes' in read_file lacks context on why it exists or what happens if the file is larger. 'headers' in http_request is undescribed.
Error handling is generic and non-actionable. Tools return 'resultError("message")' with no guidance for LLM recovery. No categorization (retryable vs. permanent), no suggestion for next steps, no constraint violations explained.
Destructive/sensitive operations lack confirmation or dry-run support. 'make_call', 'flashlight', 'global_action', 'http_request', and 'human_command' all modify state or trigger side effects without requiring explicit confirmation, inviting accidental execution.
http_request exposes raw HTTP layer with no input sanitization or timeout enforcement documented. LLMs can pass arbitrary payloads/headers. Describe validation rules (timeout bounds, header restrictions, body size limits) in parameter descriptions.
Parameter relationships undocumented. 'human_command' accepts 'command', 'text', and 'request' as aliases with no explanation of which is preferred or how they interact. LLMs will pass multiple versions.
No default values documented for optional parameters. 'language_tag' in human_command, 'camera_id' in flashlight, 'query' in list_apps are optional but lack guidance on what the default behavior is.
Tool composition breaks chain. 'search_contacts' returns 'phone' field, but 'make_call' expects 'phone_number' parameter. Mismatched field names force LLM to reason about mapping rather than direct chaining.