Phone Harness MCP
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PHONE_HARNESS_API_KEY | No | Your Phone Harness Cloud API key (pck_…). Used for local stdio mode; can be omitted if the machine is already signed in with `phone-harness cloud login`. In hosted HTTP mode each request supplies its own bearer instead. | |
| PHONE_HARNESS_CLOUD_API | No | The Phone Harness Cloud API endpoint to forward requests to. | https://api.phone-harness.com |
| PHONE_HARNESS_MCP_PUBLIC_URL | No | The URL clients use to reach the server; required with the OAuth issuer. | |
| PHONE_HARNESS_MCP_OAUTH_SCOPE | No | The scope advertised to OAuth clients. | phone:drive |
| PHONE_HARNESS_MCP_OAUTH_ISSUER | No | Set to the OAuth authorization server to publish protected-resource metadata. Unset means API keys only. | |
| PHONE_HARNESS_MCP_ALLOWED_HOSTS | No | Host header values to accept (DNS-rebinding protection). '*' disables the check; off on Vercel. | * |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| phone_list_available_devicesA | List the phones running on this account, whose ids the other tools take as |
| phone_start_deviceA | Start a phone and wait until it is ready; returns its device id. With nothing named, the account's default phone (a temporary Android emulator) starts. |
| phone_stop_deviceA | End a running phone session so it stops billing. Anything not saved on the phone is lost. |
| phone_get_screen_sizeB | The phone's screen size in the coordinate space the tap and swipe tools use. |
| phone_take_screenshotA | Take a screenshot of the phone. Use it to understand what is on screen when the text list is not enough. The image is usually smaller than the screen; the text before it says how to convert a point you see into screen coordinates. Do not reuse an old screenshot: the screen changes. |
| phone_save_screenshotA | Save a screenshot to a file on this machine: PNG when the name ends in .png, else JPEG. Full size unless |
| phone_list_elements_on_screenA | List the text visible on screen with the center of each piece, ready to tap with phone_click_on_screen_at_coordinates. On Android the positions come from the accessibility tree; on an iPhone from reading the pixels. Call it again after the screen changes. |
| phone_click_on_screen_at_coordinatesA | Tap the screen at (x, y) in screen coordinates, such as a center from phone_list_elements_on_screen. |
| phone_long_press_on_screen_at_coordinatesB | Press and hold at (x, y) in screen coordinates for |
| phone_swipe_on_screenA | Swipe in a direction: the way the finger moves, so "up" reveals what is below. Starts at (x, y), or the screen center, and travels |
| phone_type_keysA | Type text into the focused field. Tap the field first so the keyboard is up; text sent with nothing focused goes nowhere. |
| phone_press_buttonB | Press a system button: HOME, BACK (Android; an iPhone has none), APP_SWITCHER, or ENTER. |
| phone_list_appsB | List the apps installed on the phone: package ids on Android, bundle ids on an iPhone. Any of them can be passed to phone_launch_app. |
| phone_launch_appA | Open an app by the name on its icon ("Settings", "Notes", "Chrome") or, on Android, its package id. |
| phone_get_foreground_appA | Which app is in front right now. Not every phone reports it; then take a screenshot instead. |
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 15 tools
Each tool targets a clearly distinct action or resource: capture vs save screenshot, list elements vs get screen size, device lifecycle vs app lifecycle vs input actions. The descriptions reinforce the boundaries, especially around coordinates, screenshots, and device sessions.
All tools use a consistent `phone_` prefix and snake_case with verb-led names such as `phone_list_available_devices`, `phone_click_on_screen_at_coordinates`, and `phone_start_device`. The convention is predictable throughout the set.
Fifteen tools is well-scoped for a phone automation harness, covering device management, screenshots, screen inspection, input, and app control without redundant tools. Each tool has a clear role in the workflow.
The surface covers the core mobile automation lifecycle: start/stop/list devices, inspect screen, interact via tap/long-press/swipe/type/system buttons, and list/launch apps. Minor gaps exist, such as app installation/uninstallation or richer system key events, but the main workflows are covered.