ios-device-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| IOS_DEVICE_MCP_PORT | No | Driver port (default 22087). | 22087 |
| IOS_DEVICE_MCP_DEVICE | No | UDID or name of the device to use. If neither this nor a tool's `device` argument is set, the server only picks a device that is physically connected over USB (it never picks a Wi-Fi-only device implicitly). | |
| IOS_DEVICE_MCP_TEAM_ID | Yes | Required. Your Apple developer Team ID, used to sign the runner. Found in Xcode > Settings > Accounts (select the team) or on developer.apple.com under Membership. | |
| IOS_DEVICE_MCP_AUDIO_DEVICE | No | Mac mic name substring for recordings (default: first non-iPhone/iPad input). | |
| IOS_DEVICE_MCP_BUNDLE_PREFIX | No | Runner bundle ID prefix (default `dev.iosdevicemcp.<team>`). | dev.iosdevicemcp.<team> |
| IOS_DEVICE_MCP_RECORDINGS_DIR | No | Where WAV recordings go (default `.build/recordings`). | .build/recordings |
| IOS_DEVICE_MCP_ALLOW_DEVICE_REGISTRATION | No | Set to `1` to let the build register a new device in your team. | 0 |
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 |
|---|---|
| list_devicesA | List physical iPhones/iPads known to this Mac, with connection state. The device tools use by default is marked. |
| select_deviceA | Choose which device later calls use when they don't pass "device". Lasts for this server session and is shared by every agent using it, so parallel agents on different devices should pass "device" instead. Omit device to clear the choice. |
| list_appsC | List apps installed on the device. |
| build_appA | Build an Xcode project/workspace scheme for the device and (by default) install it. Returns the bundle ID. Signing uses the project's own settings. |
| install_appB | Install a built .app (or .ipa) onto the device. |
| uninstall_appB | Uninstall an app (and its data) from the device. |
| launch_appB | Launch (or relaunch) an app in the foreground. With captureLogs, the app's console output — print/NSLog and os_log/Logger messages — is buffered for get_app_logs. |
| get_app_logsA | Read console output captured from an app started with launch_app captureLogs=true. os_log/Logger lines look like |
| terminate_appC | Force-quit an app. |
| start_driverA | Start the on-device XCUITest driver (UI tools start it automatically). The first run on a device builds the runner and iOS asks for the passcode to allow UI automation. |
| stop_driverC | Stop the on-device driver. |
| screenshotA | Take a screenshot. By default it is scaled to screen points, so image pixel coordinates equal tap coordinates. |
| describe_uiA | Accessibility tree of the foreground app (plus any system alert), one element per line: Type "label" #identifier value=… @(centerX,centerY) WxH. Coordinates are in points and can be passed to tap. |
| tapB | Tap at screen coordinates (points). |
| tap_elementB | Find an element by text/identifier/type, waiting for it to appear, and tap its center. |
| wait_for_elementB | Wait until an element appears (or disappears with gone=true). |
| double_tapB | Double-tap at coordinates (points). |
| long_pressB | Press and hold at coordinates (points). |
| swipeC | Drag from one point to another (points). |
| scrollA | Scroll the content in a direction ("down" reveals content further down) by swiping from the middle of the screen. |
| type_textA | Type into the focused text field (tap the field first). Use \n for return. |
| press_buttonC | Press a hardware button. "home" goes to the home screen. |
| open_urlC | Open a URL or deep link (custom scheme or universal link) on the device. |
| set_volumeA | Set the device's media volume by pressing the volume buttons toward the level, verifying each step on the system volume indicator. iOS volume has 16 steps, so levels round to the nearest 1/16. Returns the final level. |
| record_audioA | Record the Mac microphone for a number of seconds (e.g. to capture what the device plays). Returns the WAV path. |
| list_app_filesA | List files in an app's data container (Documents, Library, tmp…). Works for development-signed apps only. |
| pull_fileB | Copy a file out of an app's data container to the Mac. Can wait for the file to appear, or to be written after the last launch_app. Small text files are returned inline. |
| set_orientationB | Rotate the device's interface orientation. |
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 28 tools
Most tools map to a distinct action+target (install_app vs launch_app vs terminate_app, list_apps vs list_app_files, tap vs tap_element vs double_tap vs long_press). Minor overlap remains: scroll is essentially a directional convenience over swipe, and tap_element implicitly waits for an element like wait_for_element, but the descriptions make the intended split clear enough that misselection is unlikely.
The set is overwhelmingly verb_noun snake_case (open_url, install_app, launch_app, get_app_logs, set_orientation, pull_file). Deviations are bare verbs/nouns for gestures and capture (tap, swipe, scroll, long_press, screenshot, describe_ui), which are conventional and still readable, but slightly break the pattern.
28 tools is on the heavy side, but the domain genuinely spans device selection, app build/install lifecycle, UI automation, input, media, and file extraction, and nearly every tool earns its place. The count is defensible rather than padded, though the driver start/stop pair could be folded into automatic management.
Coverage is broad and closed-loop: build → install → launch → interact → inspect → pull logs/files → terminate/uninstall, plus orientation, volume, audio, and screenshots. The main gap is one-directional file access—pull_file exists but there is no push_file/upload into an app container—plus no video capture, both of which agents can work around or that fall outside the core purpose.