Loading ToolBench
A CLI MCP server for ad-hoc UI testing of Android & iOS apps — a tight act+observe loop, device-condition control, log/crash & network capture, OCR targeting, accessibility audits, and session recording that exports a replayable flow.
Manos MCP provides 19 tools with consistent naming (verb_noun pattern: list_devices, inspect_screen, tap, etc.) and basic descriptions. All tools have input schemas with typed parameters and descriptions. However, descriptions are terse (avg ~40 chars, well below the 194-char baseline), lack context on WHEN to use each tool, and omit recovery guidance. Output schemas are not documented. Error handling is absent from visible code. No tool annotations (readOnlyHint/destructiveHint). Parameter descriptions are minimal ('Device identifier', 'X coordinate') without format constraints or validation rules. The server is well-structured but falls short of production-grade LLM-optimized tooling.
Run accessibility audit on the current screen
Check platform support and capabilities for a device
Export recorded session as a replayable Maestro flow
Find elements by various criteria
Find elements by text content
Get device logs and crash information
Type text into the focused field
Capture the current screen state and UI hierarchy
List connected Android emulators/devices and iOS simulators
Descriptions are terse (avg ~40 chars vs 194-char baseline). Most lack context on WHEN to use the tool, prerequisites, or what the LLM should do next. E.g., 'Tap on a screen element by id or coordinates' does not explain when to call tap vs long_press, or what inspect_screen must be called first.
Output schemas are not documented. Tools like inspect_screen, find_elements, and export_flow return complex hierarchies or YAML, but the response structure is not visible in the tool definition. LLMs cannot plan downstream calls without knowing what fields to expect.
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 definition. LLMs cannot distinguish safe tools from destructive ones without explicit hints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
Long press on a screen element
Perform OCR on the current screen to find text
Press a key on the device
Execute a Maestro flow on a device
Apply device conditions (appearance, orientation, network, locale, etc.)
Start capturing network traffic
Start recording a session for later export
Stop network capture and retrieve captured traffic
Swipe across the screen
Tap on a screen element by id or coordinates
Parameter descriptions lack format constraints and validation rules. E.g., 'direction' in swipe accepts 'UP, DOWN, LEFT, RIGHT' but the description does not state this as an enum. 'lines' in get_logs has no min/max. LLMs will hallucinate invalid values.
No error handling or recovery guidance visible in tool definitions. If a device is not found, or a tap fails, the LLM has no guidance on what to do next. Error responses should include actionable next steps (e.g., 'Device not found. Call list_devices() to see available devices.').