Mobile MCP

The server holds no API keys of its own and does not forward client tokens, but it does nothing to narrow the authority it runs with. Every tool reaches whichever device the model names among all phones, emulators and simulators visible on the machine, and the remote-fleet tools act on the device-cloud account the user logged into, which is billed. Helper processes inherit the server's full environment. There is no device allowlist, read-only identity or per-request authorization, so a misused session can act on a personal phone with all of its signed-in apps.

As a tool server, Mobile MCP leaves approval to the MCP host and does not ask anyone itself. Every tool is registered with read-only, destructive and open-world hints, and the batch tool is flagged destructive, which gives a host something to gate on. The hints are not accurate on every state-changing tool (typing, tapping and installing apps are not marked destructive, though they can send messages or change data, and the device-log tool is marked read-only even though it can save a file), and there is no preview, dry-run or server-side read-only mode. Uninstalling apps, releasing a remote device and sending typed text cannot be undone.

Tools are fairly narrow device actions with typed arguments: coordinates, durations, locations and log limits are bounded, enums restrict directions and orientations, and batch steps are re-validated against each tool's schema. Paths the server writes to are checked against an extension list and a working-or-temp-directory allowlist. Other arguments are looser: the URL tool checks only the scheme and can open any host, the install tool accepts an app file from anywhere on the host, and package names and element refs are passed through as given. Every tool, including install, uninstall and remote-device allocation, is enabled by default with no way to select a smaller set.

The server never hands model text to a host shell: every helper (mobilecli, and adb, go-ios and simctl in legacy mode) is started with a fixed binary and an argument list. Its code-execution surface is on the device: the model can install any app bundle it can name from the host's disk and then launch it, and the server installs its own helper app on iOS Simulators at first use. The only boundary around that code is the device itself. A real phone or an Android emulator is a separate system, but iOS Simulator apps run as ordinary processes of the logged-in macOS user, so an untrusted app bundle installed there runs with the user's own access to files and network. The server has no option to limit which kinds of device or which app files may be used.

Everything the agent reads through this server comes from the device: on-screen text and labels from any app or web page, the clipboard, device logs and crash reports. All of it is returned to the model as plain text with no marker saying it is untrusted, and some server outputs carry instructions to the model alongside the data. Nothing in the server limits what a session can do after reading such content. If a message, web page or notification on the device hijacks the agent, the default tools let it read private data (clipboard, messages on screen) and send it out by opening a URL on the device browser or typing it into an app, and uninstall apps or send messages, with no human asked by the server.

The server has no memory store, does not load .env files, instruction files or project configuration from the working directory, and reads nothing it wrote back into the model's context. Its only configuration is environment variables set by whoever launches it. The files it can write (screenshots, logs, recordings) are limited to image, log, text and video extensions, so it cannot create instruction or settings files that other tools auto-load. Device state such as installed apps persists on the device, but that is the device, not the agent's memory.

The server loads no plugins and connects to no other MCP servers. The third-party code it handles is app packages: the model can install any .apk, .ipa, .zip or .app file it names from the host and launch it, with no signature, hash or allowlist check and no consent step in the server, and the server silently installs its own helper agent onto iOS Simulators the first time it uses one. Installed apps run as separate processes on the device; on an iOS Simulator that means the logged-in user's account on the host. The shipped launch configs fetch the latest published server package on every start, which is the project's own distribution rather than a runtime extension and is not scored here.

The server keeps no secrets of its own beyond an optional HTTP bearer token read from the environment, and remote-fleet login is handled by the separate mobilecli tool. Usage telemetry to PostHog (plus a Scarf pixel) is on by default; it is content-free, sending tool names, durations, device counts, the client name and a hashed host id, and can be turned off with an environment variable. However, every tool call's full arguments and full text result are written to stderr by default, and to a file when LOG_FILE is set, with no redaction, so text typed into apps (including passwords), clipboard contents and device logs end up in the MCP host's logs. Clipboard and device-log contents also go to the model unfiltered.

Every tool registered through the server's helper writes a plain-text line with the tool name and full arguments before it runs, and another with the full result afterwards. By default these lines only go to stderr, where whether they are kept depends on the MCP host; a durable file with timestamps exists only when the operator sets LOG_FILE. The record is unstructured, has no actor, session or request identifiers, and the steps inside a batch are not recorded one by one (only the batch's arguments). When the file is enabled it is appended synchronously before each action, but it sits wherever the operator points it with no tamper protection.

Some operations have hard bounds: screenshot and crash-report commands time out after 30 seconds with an 8 MB output cap, log capture stops after at most 10,000 entries or 30 seconds of silence, and the login prompt times out after 15 seconds. Most device commands, though, run with no timeout, a batch can contain any number of steps, and the model chooses how long to wait for a billed remote device and how long a screen recording runs, with no maximum. Screen recordings and the login flow run as background processes, and when the server is stopped it simply exits: background processes are not killed and remote devices stay reserved until released.