Loading ToolBench
Local MCP capabilities provider for Expo - enables AI models to interact with Expo projects, including Expo Router sitemap queries, DevTools control, app log collection, and mobile device automation (Android/iOS)
Expo MCP provides 8 tools with reasonable naming and description coverage. All tools have explicit descriptions and most have input schemas. However, there are significant gaps in parameter descriptions, inconsistent schema completeness, and missing output schema documentation. Tool naming follows verb_noun pattern well (expo_router_sitemap, open_devtools, collect_app_logs, tap_screen, take_screenshot, find_view_by_test_id, tap_by_test_id, take_screenshot_by_test_id). Descriptions range from adequate to good (90-150 chars typically). The main issues are: (1) inconsistent parameter type specifications, some inputs shown with descriptions but JSON Schema format unclear in source; (2) no visible output schemas, tool responses return {content: [...]} wrapper but field structure not documented; (3) missing descriptions for some parameters (e.g., 'appId' in collect_app_logs has description but logLevel parameter description exists); (4) no error handling guidance visible in tool definitions; (5) no composition patterns documented (e.g., find_view_by_test_id → tap_by_test_id chain). The server uses tool annotations (readOnlyHint, destructiveHint, idempotentHint) correctly, which is a positive signal. Overall, definitions are above average community standard but fall short of production-grade clarity.
Collect logs over a short time window from the native device (Android logcat / iOS syslog) and/or the JavaScript console. Use this to debug runtime errors, crashes, or unexpected behavior in a running app.
List all routes (the sitemap) of the current Expo Router project. Use this when you are working with Expo Router and need to know which routes or screens exist in the app.
Find a UI element by its testID/accessibility ID and return its properties and location
Open React Native DevTools for the running app to debug JavaScript, inspect the component tree, and view console output. Requires a running dev server (Metro) for the project.
Take a full-screen screenshot from the running app and save it to the specified output path
Take a screenshot of a specific UI element by its testID/accessibility ID
Output schemas not documented. Tools return {content: [...]}, but LLM cannot infer structure of content items, success/failure fields, or per-item data. This forces LLMs to guess at response structure and may cause parsing failures.
tap_screen and take_screenshot have minimal descriptions (<70 chars). No explanation of when to use tap_screen vs tap_by_test_id, or side effects.
Parameter 'platform' accepts string type but is not explicitly constrained as enum in visible schema. Descriptions say 'android' or 'ios', but LLM could pass invalid values. JSON Schema enum constraint not visible in source.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 52 | - | v1 |
Tap on a UI element by its testID/accessibility ID
Simulate a tap on the device screen at the specified x,y coordinates
No error handling guidance in tool descriptions. If a device is not booted, or Metro dev server is not running, what should the LLM do? Are errors retryable? This forces LLMs to guess recovery strategies.
No composition guidance. find_view_by_test_id and tap_by_test_id are related but not documented as a chain. collect_app_logs + open_devtools could work together for debugging, but no hint about ordering or data flow.
collect_app_logs 'durationMs' parameter has 0-10000 range constraint, but no guidance on typical values or why 10 seconds is the max. For debugging, LLM may not know if 1000ms or 5000ms is appropriate.