Skip to content

MCP Tools

The MCP server exposes 74 tools organized into five conceptual families. All tools are available through Claude Code’s tool-calling interface.

NeedUseExample
Read React component tree, store state, navigationCDPcdp_component_tree, cdp_store_state
Tap, swipe, type, scroll on the deviceDevicedevice_press, device_fill, device_swipe
Replay or self-repair a known flowActionscdp_run_action, cdp_repair_action
Run E2E flows, capture proofTestingmaestro_run, proof_step
Assert internal state instead of pixelsMacro-Assertsexpect_redux, expect_route
Check environment healthCDPcdp_status (always call first)
Debug crashes spanning JS + nativeCDPcollect_logs with multiple sources

Read React internals via Chrome DevTools Protocol over a WebSocket connection to Hermes.

Connection lifecycle: cdp_status (auto-connect) → cdp_connect (explicit) → cdp_disconnect (teardown) → cdp_targets (list without connecting) → cdp_restart (full process restart) → cdp_open_devtools (attach DevTools)

Component inspection: cdp_component_tree (filtered fiber tree) → cdp_component_state (hook state by testID) → cdp_diagnostic_renderers (fiber-root invisibility diagnosis)

Navigation: cdp_navigation_state (current route) → cdp_nav_graph (full graph with go-to-screen) → cdp_navigate (by screen name)

State management: cdp_store_state (Redux/Zustand/React Query) → cdp_dispatch (Redux action + read-back) → cdp_mmkv (MMKV read/write)

Logs & events: cdp_console_log, cdp_network_log, cdp_network_body, cdp_wait_for_network, cdp_error_log, cdp_native_errors, cdp_metro_events, collect_logs (multi-source)

Profiling & inspection: cdp_heap_usage, cdp_cpu_profile, cdp_object_inspect, cdp_exception_breakpoint, cdp_set_shared_value

Interaction & utilities: cdp_interact (press/type/scroll by testID via fiber tree — preferred for JS-level interaction), cdp_evaluate (raw JS), cdp_reload (full reload), cdp_dev_settings (dev menu)

Native interaction. iOS routes through the in-tree rn-fast-runner /command endpoint; Android routes through the agent-device CLI (3-tier daemon → fast-runner → CLI dispatch). Requires an open session (device_snapshot action=open).

Session: device_listdevice_snapshot (open/snapshot/close) → device_screenshot

Interaction: device_find (by text) → device_press (by @ref) → device_fill (type text) → device_swipe / device_scroll / device_scrollintoviewdevice_backdevice_longpressdevice_pinch

Utilities: device_permission (grant/revoke) → device_batch (multi-step sequence)

Helpers (filed alongside CDP in code): device_deeplink, device_accept_system_dialog, device_dismiss_system_dialog, device_focus_next, device_pick_date, device_pick_value, device_record, device_reset_state.

Record / replay / self-repair persistent flows. See the Actions concept guide for why the LLM/pragmatic hybrid matters.

Replay & repair: cdp_run_action (orchestrates maestro_run + auto-repair + retry; persists RunRecord with phase timings) → cdp_repair_action (fuzzy-patches stale testID against live snapshot; refuses on human edits, >3 repairs/24h)

Recording → action promotion: cdp_record_test_startcdp_record_test_annotate (mid-recording state checks) → cdp_record_test_stopcdp_record_test_generate (raw Maestro YAML) → cdp_record_test_save / cdp_record_test_save_as_action (promote to first-class action) → cdp_record_test_list / cdp_record_test_load

E2E testing and proof capture — work even when the app is crashed or on native screens.

cdp_auto_loginmaestro_run / maestro_generatemaestro_test_allproof_stepcross_platform_verify

State-assertive replays — assert internal app state instead of pixels. The differentiator vs Maestro Cloud / BrowserStack / KaneAI: those compare screenshots; these read Redux / route / fiber state directly.

expect_redux (state.path equals value) · expect_route (active route name) · expect_visible_by_testid (testID present in tree) · expect_text (component text content)