Loading ToolBench
expo-mcp exhibits moderate structural quality but suffers from inconsistent schema visibility, missing parameter descriptions across multiple tools, and underdeveloped error recovery guidance. Naming is generally clear (verb_noun convention observed), but 7 of 12 tools lack complete input schema documentation in the visible code. Parameter descriptions are sparse or missing, e.g., tap_on's 'repeat' parameter has a description, but scroll's 'amount' lacks detail on what '0-1' means in practice (pixels? screen height?). Error handling returns text blobs without actionable recovery paths. STDIO transport caps the overall score regardless of definition quality. The server is functional for basic mobile automation but falls short of production-grade agent-friendly design.
Input text into a focused text field
Inspect the current view hierarchy and accessibility information from the app
List available iOS simulators and Android emulators
Press a hardware key on the device
Run Maestro test flows from YAML files
Take a screenshot of the current app state
Scroll in a direction or to a specific element
Start an Expo development session and optionally launch the app on a device
Parameter descriptions missing or underdeveloped across multiple tools. scroll's 'amount' parameter lacks detail on unit or scale; press_key's 'key' parameter provides only a vague example 'BACK, HOME, ENTER' without listing all valid keys or explaining the constraint.
inspect_view_hierarchy, run_maestro_flow_files, and stop_session lack detailed descriptions of what information they return or when to invoke them. LLMs cannot determine utility without understanding the output shape.
Output schemas are not documented for any tool. The LLM cannot infer what fields verify_screenshot_matching returns (success boolean? similarity_score? metadata?) or what list_devices returns (array of device objects? what fields each?).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | 2024-11-05+ | v1 |
Stop the Expo development session and clean up resources
Swipe from one point to another on the screen
Tap on an element identified by text, id, or position
Verify the current screenshot matches a reference image
Error handling returns unstructured text errors ('Error: <message>') with no recovery guidance. Example: if start_session fails because the device is not found, the error should suggest 'Try list_devices() to see available devices', current implementation just returns the error message.
Parameter constraints are expressed in descriptions but not in schema. Example: tap_on's x/y coordinates are documented as '0-1, percentage of screen width/height' but the schema has no minimum/maximum, allowing invalid values like x=2.5 or x=-1.
press_key accepts a free-form 'key' string with no enum. Valid keys are likely 'BACK', 'HOME', 'ENTER', etc., but the LLM could pass 'QUIT', 'ESCAPE', or 'xyz' without validation, causing silent failures.
scroll's 'direction' is an enum (good), but 'amount' is a bare number. LLM cannot determine if 0-1 is percentage of screen height or a count of swipes. Description says 'Amount to scroll (0-1, percentage)' but no min/max in schema.
tap_on has three ways to identify an element (id, text, x/y position) but no guidance on precedence or mutual exclusivity. If an LLM passes all three, which takes precedence? Current schema suggests all are optional, inviting ambiguous calls.