rn-device-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ADB_PATH | No | Path to the adb executable. If not set, adb is found via ANDROID_HOME, ANDROID_SDK_ROOT, ~/Library/Android/sdk, then PATH. | |
| ANDROID_HOME | No | Android SDK root used to locate adb. | |
| ANDROID_SDK_ROOT | No | Android SDK root used to locate adb. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ios_simulatorsB | Lists simulators with runtime, state and udid; booted ones first. |
| ios_bootA | Boots a simulator by udid or name (e.g. 'iPhone 17 Pro'), waits until it is ready and brings Simulator.app to front. |
| ios_shutdownA | Shuts down the booted simulator (or the given one). |
| ios_screenshotA | Captures the simulator screen and returns it as an image. Use it to see what the app is showing right now. |
| ios_open_urlB | Opens a URL in the simulator: a deep link (myapp://...), a universal link, or an Expo dev-client URL (exp+myapp://...). |
| ios_launch_appA | Launches an installed app by bundle id. relaunch: true terminates it first (cold start). |
| ios_terminate_appC | Kills the app process on the simulator. |
| ios_install_appB | Installs a simulator build (.app directory, e.g. from |
| ios_appsA | Lists installed apps with bundle ids. userOnly (default true) hides Apple's system apps. |
| ios_logsA | Recent unified-log lines from the simulator. Filter by process (the app's product name, e.g. 'MyApp') and/or a substring. JS console output from RN shows up under the app process. |
| android_devicesA | Lists emulators and USB devices known to adb, with serial and state. |
| android_screenshotA | Captures the device screen and returns it as an image. |
| android_open_urlB | Opens a deep link or URL with an ACTION_VIEW intent. |
| android_launch_appB | Launches an app by package name. relaunch: true force-stops it first. |
| android_stop_appC | Force-stops the app. |
| android_install_apkC | Installs (or reinstalls, keeping data) an APK. |
| android_reverse_metroA | Runs |
| android_dev_menuA | Sends the menu key, which opens the React Native dev menu in debug builds. |
| android_inputA | Low-level input: tap at x,y (pixels from android_screenshot at maxDimension 0), type text into the focused field, or send a keyevent such as KEYCODE_BACK / 4. |
| android_logcatA | Recent logcat lines. By default only ReactNativeJS (console.*), ReactNative and crash tags; all: true lifts the filter. clearAfter: true empties the buffer so the next call shows only new lines. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 20 tools
Tools are cleanly partitioned by platform prefix and a distinct action (boot, shutdown, install, launch, terminate, screenshot, logs), so an agent can pick correctly in almost all cases. The only mild overlaps are ios_launch_app vs ios_open_url (cold start vs deep link) and android_dev_menu vs android_input's KEYCODE_MENU keyevent, both of which the descriptions clarify.
A consistent platform_action scheme (ios_*, android_*) with snake_case throughout makes the surface predictable. Minor deviations: list tools use bare nouns (ios_simulators, ios_apps, android_devices, ios_logs, android_logcat) instead of a verb, and the platform sets are asymmetric (ios_boot/ios_shutdown exist, android counterparts do not).
20 tools is on the heavy side for a device-control server, though the count is partly explained by covering two platforms. Several tools are thin one-off wrappers (android_reverse_metro, android_dev_menu) that could arguably be folded into the input/log utilities.
The iOS lifecycle (boot, install, launch, terminate, screenshot, logs, apps) and the Android equivalents are broadly covered with no severe dead ends. Notable gaps: there is no iOS UI interaction tool (no tap/type equivalent to android_input), no way to start/boot an Android emulator, and no uninstall or clear-data operations on either platform.