Screenshots alone force a model to guess at coordinates; the flat UI tree, searchable and leaf-ranked, means it can find the element and then tap it. The scripting tool is the escape hatch for sequences that would take a dozen round trips — a short UIAutomator or XCUITest snippet runs on the device in one call.
A device-automation server with an on-device driver on each phone — UIAutomator on Android, XCUITest on iOS — normalised behind one flat element model.
- Device discovery across iOS and Android, with several devices driven in the same session
- The screen as a JPEG screenshot, and the UI as a flat element tree with search and a limit, off-screen elements dropped unless you ask for them
- Input that covers real interaction: tap, double-tap, long-press with a duration, swipe between coordinates, typing into the focused element, and hardware or navigation buttons including home, back and the d-pad
- App lifecycle: list what is installed, launch by bundle ID or package name, force-stop, and install from a file on the host — .apk on Android, .app or .ipa on iOS
- Sandboxed on-device scripting: UIAutomator-style JavaScript on Android with uiDevice, By and Until, and XCUITest-style JavaScript on iOS with app, springboard and openApp, each in a fresh sandbox with runaway scripts killed
- Bootstrapping handled for you — the driver app is installed, a port allocated and the on-device server started and health-checked on first use, then proxied over localhost with a per-device bearer token
Node.js 18+ and the platform toolchain for whatever you are driving: the Android SDK with adb on PATH for Android, Xcode with xcrun and simctl for the iOS Simulator, and Xcode plus devicectl and iproxy for a real iOS device. Runs from npm as @srmorete/mobile-device-mcp over stdio; MDMS_PORT_ANDROID and MDMS_PORT_IOS set the base ports, assigned sequentially per device.
One command — npx -y @srmorete/mobile-device-mcp