What can you do with this server?

Control local iOS Simulators and Android Emulators for agent-driven app testing. * Check native tooling, device counts, and WebDriverAgent status. * List, boot, and shut down iOS Simulators and Android Emulators/AVDs. * Install, launch, terminate, reset, or uninstall apps; read bounded app logs and crash reports. * Set permissions, simulated location/routes, push notifications, SMS, clipboard, status bar, battery, network, fingerprint, proxy, sensors, calls, snapshots, biometrics, lock state, locale, appearance, and accessibility settings. * Open URLs/deep links and add media or contacts. * Capture screenshots and record screen video. * Inspect UI trees, list elements, tap/double-tap/long-press, swipe, type text, press keys, handle alerts, dismiss keyboard, and rotate/set orientation. * Run iOS accessibility audits and manage iOS keychain certificates. * Serve via local stdio or loopback Streamable HTTP; physical devices, arbitrary shell, and raw native passthrough are rejected.

Which integrations are available for this server?

Lets agents inspect, control, and test Google Android Emulators: booting configured AVDs and shutting them down, installing APKs, launching/terminating/resetting apps, UI automation by element or coordinate, screenshots and screen recording, app logs and crash buffers, runtime permissions, simulated location, battery and charging state, network speed/latency profiles, airplane mode, wifi and mobile data toggles, inbound SMS, fingerprints, rotation and orientation, and emulator snapshots. Provides tools for interacting with Apple's iOS Simulator platform and Apple testing services, including Simulator lifecycle management, Apple privacy-service permission granting, Apple XCTest accessibility audits of the foreground app, iOS Simulator keychain certificate management, APNs payload delivery, and simulated Face ID/Touch ID enrollment and scans. Lets agents inspect, control, and test Apple iOS Simulators: booting/shutting down and erasing devices, installing, launching, terminating, resetting, and uninstalling apps, UI automation by element or coordinate, alerts, keyboard and lock state, screenshots and screen recording, logs and crash reports, privacy-service permissions, simulated GPS location and waypoint routes, push notifications, biometrics (Face ID/Touch ID), clipboard, status bar overrides, appearance, connectivity, and accessibility settings.

How do I use mobile-simulator-emulator-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mobile-simulator-emulator-mcp List my available simulators and emulators" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

mobile-simulator-emulator-mcp

by gitsoufiane

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Mobile Simulator & Emulator MCP

A local Model Context Protocol server that lets coding agents inspect, control, and test Apple iOS Simulators and Google Android Emulators. It exposes 53 typed tools for device lifecycle, app discovery and management, UI automation by element or coordinate, system alerts, screenshots and screen recording, logs and crash reports, permissions, location and routes, biometrics, lock state, locale, appearance/accessibility and accessibility audits, network proxies and certificates, emulator snapshots, calls, sensors, and other platform-specific test conditions.

It defaults to stdio and can also serve Streamable HTTP on loopback with --listen.

It uses:

xcrun simctl for iOS Simulator lifecycle, apps, URLs, and screenshots.
Appium WebDriverAgent for iOS UI trees and input.
Google adb and emulator for Android lifecycle, apps, UI trees, screenshots, and input.

Physical devices are intentionally rejected.

Requirements

macOS with Xcode and at least one installed iOS Simulator runtime.
Android SDK Platform Tools and Android Emulator.
Node.js 22.18+ or 24.2+.
A booted simulator/emulator for interaction tools. mobile_boot_device can boot an installed target returned by mobile_list_devices.

Verify the native tools:

xcrun simctl list devices
adb devices -l
emulator -list-avds

Related MCP server: Simulator MCP

Quick start

Run it straight from GitHub. npm clones the repository, installs dependencies, and builds it on first use:

npx -y github:gitsoufiane/mobile-simulator-emulator-mcp

Or build from source:

git clone https://github.com/gitsoufiane/mobile-simulator-emulator-mcp.git
cd mobile-simulator-emulator-mcp
npm ci --ignore-scripts
npm run build

Start the devices you want the agent to use:

# iOS: boot a Simulator from Xcode or the command line
open -a Simulator

# Android: list and start an installed AVD
emulator -list-avds
emulator -avd <AVD_NAME>

Then verify both native toolchains:

xcrun simctl list devices
adb devices -l
npm run live

The first iOS UI interaction builds and launches WebDriverAgent through Xcode. It can take several minutes. Later calls reuse that process until the MCP server exits or another iOS Simulator is selected.

Configure an MCP client

Any MCP client that supports local stdio servers can run this server. Add one of the following server definitions to the client's MCP configuration.

With npx (no clone needed):

{
  "mcpServers": {
    "mobile": {
      "command": "npx",
      "args": ["-y", "github:gitsoufiane/mobile-simulator-emulator-mcp"]
    }
  }
}

From a local build, replacing the absolute path:

{
  "mcpServers": {
    "mobile": {
      "command": "node",
      "args": [
        "/absolute/path/to/mobile-simulator-emulator-mcp/dist/src/index.js"
      ]
    }
  }
}

HTTP mode (`--listen`)

For MCP clients that connect by URL instead of spawning a stdio process (for example flue's connectMcpServer), start the server in Streamable HTTP mode:

node dist/src/index.js --listen 3000
# ready on http://127.0.0.1:3000/mcp

The HTTP listener binds to 127.0.0.1 only and has no authentication — it is strictly a same-machine transport with the same trust model as stdio. As the MCP transport specification requires, it rejects with HTTP 403 any request whose Host or Origin header is not 127.0.0.1, localhost, or [::1], so a web page cannot reach it through DNS rebinding. Each MCP session gets its own protocol server, and all sessions share one set of device controllers, so they share one WebDriverAgent process. Sessions are cleaned up on disconnect. stdio remains the default when --listen is not given.

Restart the MCP client after changing its configuration. The first calls should be:

mobile_doctor with {}.
mobile_list_devices with {}.
Use the returned ios:..., android:..., or android-avd:... ID in later calls.

By default, .app and .apk installation paths are resolved beneath the MCP process working directory. Clients that launch the server from the active agent project—such as Pi's MCP adapter when no cwd is configured—therefore need no extra environment setting.

If another MCP client starts the server from a fixed directory, set that client's cwd to the mobile project. MOBILE_MCP_APP_ROOT remains available as an optional explicit override.

The server writes MCP protocol messages only to stdout. Diagnostics and WebDriverAgent logs go to stderr.

Recommended agent workflow

Call mobile_doctor.
Call mobile_list_devices and keep the returned stable ID.
Boot a shutdown target if needed.
Install and launch the app. Use mobile_list_apps to look up the exact bundle ID or package name instead of guessing, and mobile_get_foreground_app to confirm the launch landed.
Set permissions or simulated location needed by the scenario.
Call mobile_list_elements before using coordinates. It returns compact elements with tap-ready center coordinates; pass query to find one element. Use mobile_take_screenshot for visual context and mobile_get_ui_tree only when you need the full native hierarchy.
Interact with mobile_tap, mobile_swipe, mobile_type_text, and mobile_press_key.
Re-read the UI tree or screenshot after each state-changing action.
Collect mobile_get_logs when a workflow fails. Use mobile_reset_app only when a clean app state is required.

Example requests

Once connected, an agent can handle requests such as:

“List my available simulators and emulators, then boot the shutdown iPhone.”
“Install the Android debug APK, launch it, and take a screenshot.”
“Open myapp://checkout/123, inspect the UI tree, and tap Continue.”
“Set the emulator location to San Francisco and test the nearby-results screen.”
“Collect the last five minutes of logs for com.example.app.”
“Reset the test app, grant location permission, and rerun the onboarding flow.”

Destructive tools run without an extra MCP-side confirmation. Configure this server only for trusted agents and disposable simulator/emulator data.

Tools

Tool	Purpose
`mobile_doctor`	Check native tools, device counts, and WDA status
`mobile_list_devices`	List iOS Simulators, running Android Emulators, and configured AVDs
`mobile_boot_device`	Boot and wait for an iOS Simulator or Android AVD
`mobile_shutdown_device`	Shut down a running target without deleting data
`mobile_install_app`	Install `.app` or `.apk` artifacts from the active project root
`mobile_launch_app`	Launch an app by bundle/package ID, optionally with a locale, iOS arguments/environment, or Android intent extras
`mobile_terminate_app`	Stop an app without clearing data
`mobile_list_apps`	List installed bundle IDs/package names (user apps by default)
`mobile_get_foreground_app`	Report which app (and Android activity) is in front
`mobile_get_logs`	Return bounded logs for one installed app
`mobile_reset_app`	Clear Android app data or uninstall an iOS app
`mobile_set_permission`	Grant/revoke Android runtime permissions or grant/revoke/reset allowlisted iOS privacy services
`mobile_set_location`	Set simulated GPS coordinates; iOS also clears the simulation or moves along a waypoint route
`mobile_send_push`	Send a ≤4096-byte APNs payload to an iOS Simulator app
`mobile_add_media`	Add photos, videos, or vCard contacts to the device library
`mobile_uninstall_app`	Uninstall an app and its data
`mobile_erase_device`	Shut down and erase an iOS Simulator
`mobile_set_clipboard`	Replace iOS Simulator pasteboard text
`mobile_get_clipboard`	Read iOS Simulator pasteboard text
`mobile_set_status_bar`	Override or clear typed iOS status-bar values
`mobile_set_appearance`	Switch light/dark appearance on either platform
`mobile_set_accessibility`	Reduce motion and screen reader (VoiceOver/TalkBack) on both; iOS Dynamic Type, contrast, transparency; Android font scale
`mobile_set_battery`	Set Android Emulator battery capacity and charging state
`mobile_send_sms`	Deliver a simulated inbound Android SMS
`mobile_fingerprint`	Touch/remove an enrolled Android Emulator fingerprint
`mobile_set_network`	Set Android Emulator speed and latency profiles
`mobile_set_connectivity`	Toggle Android Emulator airplane mode, wifi, or mobile data
`mobile_rotate`	Rotate an Android Emulator clockwise
`mobile_set_orientation`	Set an absolute orientation on either platform; Android `auto` restores sensor rotation
`mobile_open_url`	Open an allowed URL or deep link
`mobile_take_screenshot`	Return a PNG image directly to the client
`mobile_get_ui_tree`	Return iOS JSON or Android XML UI hierarchy
`mobile_list_elements`	Return compact labeled/interactive elements with tap-ready center coordinates
`mobile_tap_element`	Tap, double tap, or long press an element found by label, identifier, value, or type
`mobile_double_tap`	Double tap validated coordinates
`mobile_handle_alert`	List, accept, or dismiss the visible iOS alert, optionally by button label
`mobile_dismiss_keyboard`	Hide the software keyboard
`mobile_set_lock`	Lock or unlock the screen and report the resulting state
`mobile_simulate_biometric`	Enroll/unenroll iOS Face ID or Touch ID and deliver matching or failing scans (Xcode 27)
`mobile_record_screen`	Record a fixed-length `.mp4` beneath the app root
`mobile_get_crash_logs`	Return an app's Android crash buffer or summarized iOS Simulator crash reports
`mobile_accessibility_audit`	Run Apple's XCTest accessibility audit on the foreground iOS app
`mobile_keychain`	Add a root or regular certificate to, or reset, the iOS Simulator keychain
`mobile_emulator_snapshot`	List, save, load, or delete Android Emulator snapshots
`mobile_phone_call`	Simulate an inbound Android call and accept, hold, busy, or end it
`mobile_set_sensor`	Set Android Emulator acceleration, gyroscope, light, proximity, and other sensors
`mobile_set_proxy`	Set or clear the Android Emulator HTTP proxy
`mobile_get_screen_info`	Return screen width, height, orientation, and density
`mobile_tap`	Tap validated coordinates
`mobile_long_press`	Press and hold validated coordinates
`mobile_swipe`	Swipe between validated coordinates
`mobile_type_text`	Type into the focused field
`mobile_press_key`	Press HOME/BACK/ENTER/app-switch/volume keys as supported; Android `NOTIFICATIONS` opens the shade

Device IDs

Booted iOS: ios:<simulator-UDID>
Running Android: android:emulator-5554
Shutdown Android AVD: android-avd:<AVD-name>

Always use IDs from the latest mobile_list_devices result.

Configuration

Variable	Default	Meaning
`MOBILE_MCP_APP_ROOT`	MCP process working directory	Apps, media, and certificates are read, and recordings are written, only beneath this directory
`MOBILE_MCP_URL_SCHEMES`	empty	Comma-separated extra deep-link schemes; `http` and `https` are always allowed
`MOBILE_MCP_SHOW_XCODE_LOG`	`0`	Set to `1` for verbose Xcode/WDA diagnostics on stderr
`ANDROID_SDK_ROOT` / `ANDROID_HOME`	executable lookup	Android SDK location

Security model

stdio by default. The optional --listen HTTP transport binds to 127.0.0.1 only and rejects non-loopback Host/Origin headers (DNS-rebinding protection). There is no remote listener or authentication surface.
No arbitrary shell, adb shell, or simctl spawn tool is exposed.
Native commands use argument arrays, explicit Android serials, timeouts, and output limits.
Physical devices, device creation/deletion, raw native-command passthrough, and arbitrary host shell access are not supported.
Curated destructive operations—including app reset/uninstall and iOS Simulator erase—execute without per-call confirmation. The MCP client configuration is the trust boundary.
URL schemes, device identifiers, app IDs, permissions, coordinates, environment profiles, durations, push payloads, locales, launch environment names, intent-extra keys, proxy addresses, snapshot names, and file paths are validated.
Recordings are written only as new .mp4 files inside an existing directory beneath MOBILE_MCP_APP_ROOT; existing files are never overwritten.
The Android emulator console reports failures as KO: with exit code 0. Every console call checks for it, so a rejected command is an error, never a silent success.
WebDriverAgent is contacted only at 127.0.0.1:8100.

Treat this server like any local developer tool: it runs with the MCP client's operating-system permissions and can interact with apps displayed in test devices.

Limits

One iOS Simulator can own the WDA process on port 8100 at a time, across all stdio or HTTP sessions of one server process. Android can run concurrently.
mobile_list_elements keeps elements that have a label, identifier, or value, or that are interactive. Layout containers and iOS keyboard keys are omitted; use mobile_get_ui_tree when you need them.
mobile_get_ui_tree and Android input need the screen on and unlocked. A sleeping Android Emulator makes uiautomator dump fail, and the server reports that as an error rather than returning an empty tree.
mobile_set_accessibility splits by platform: contentSize/increaseContrast/reduceTransparency are iOS-only, fontScale is Android-only. reduceMotion and screenReader work on both; on iOS they need Xcode 27 devicectl, and Android TalkBack must be installed in the emulator image.
Android mobile_set_orientation locks rotation; pass auto to restore sensor rotation. iOS uses devicectl on Xcode 27 (works on the portrait-only home screen) and falls back to WebDriverAgent on older Xcode.
mobile_record_screen blocks for its duration (1–180 s). Android screenrecord has no audio.
mobile_get_crash_logs on iOS reads ~/Library/Logs/DiagnosticReports and keeps only reports whose coalitionName names the target Simulator.
The Android proxy is applied by the emulator process on the Mac, so use a Mac-side address such as 127.0.0.1:8888, not the guest alias 10.0.2.2.
Android mobile_set_lock unlock dismisses only the default swipe keyguard; a PIN, pattern, or password stays locked and the tool reports an error.
Android per-app locale (mobile_launch_app locale) needs Android 13+ and persists until you launch with locale: "system".
mobile_list_apps returns Android package names without display labels; iOS returns CFBundleDisplayName when the app declares one.
Android input text supports printable ASCII only. iOS typing supports Unicode through WDA.
UI trees depend on apps exposing useful accessibility labels/identifiers.
Trees and logs over one million characters return truncated: true; treat the result as incomplete.
Android Emulator has no official command to clear its last GPS fix; the release gate restores it to 0,0.
Android AVD wipe is a boot-time option, so mobile_erase_device is iOS-only.
Clipboard, cosmetic status-bar control, alerts, Face ID/Touch ID, keychain, accessibility audits, and location routes are iOS-only in the installed official tools. SMS, fingerprint, network profiles, battery state, snapshots, calls, sensors, proxy, and mobile_rotate are Android-only.
Android clipboard: the platform has no shell clipboard command (cmd clipboard reports no implementation), so clipboard stays iOS-only.
Simulated push delivery is iOS-only. Android FCM requires Firebase rather than adb.
Apple exposes no supported command for Simulator network conditioning; it remains out of scope.
App-container host paths, iCloud sync, and device create/clone/delete/rename stay out of scope: they leak host paths or manage fleets rather than test a running device.
Android foldable posture, multi-display, and screen-size overrides, plus iOS Siri, remain unimplemented.
MCP resources, prompts, and completions are not implemented. Device state changes too quickly to cache as resources, and every workflow here is better expressed as an explicit tool call.
Simulators and emulators do not reproduce all real-device sensors, performance, or hardware behavior.

Troubleshooting

`mobile_doctor` reports a missing Android command

Set ANDROID_SDK_ROOT or ANDROID_HOME to the Android SDK directory and ensure its platform-tools and emulator directories are installed. You can also add both directories to PATH.

iOS UI calls time out on first use

WebDriverAgent may need several minutes to compile through Xcode. Set MOBILE_MCP_SHOW_XCODE_LOG=1 in the MCP environment to send detailed build logs to stderr.

App installation is rejected

The artifact must resolve beneath the agent project's working directory, or beneath MOBILE_MCP_APP_ROOT when explicitly configured. Android requires an .apk file; iOS requires a built .app directory for the Simulator architecture.

A deep link scheme is rejected

http and https are enabled by default. Add custom schemes as a comma-separated environment value, for example MOBILE_MCP_URL_SCHEMES=myapp,example-beta.

A device ID is rejected

Call mobile_list_devices again and use its exact current ID. Physical Android and Apple devices are intentionally unsupported.

Development and release checks

npm run check
npm run live
npm run live:deep
npm run live:tools
npm run live:extended
npm audit --omit=dev

npm run live:extended exercises every 0.5.0 tool on both platforms against Settings and Safari and restores each change: locale, launch arguments/extras, element taps, keyboard, orientation (including a landscape tap beyond the portrait width), double tap, lock, recording, crash logs, snapshots, calls and console KO: errors, sensors, proxy, reduce motion, TalkBack/VoiceOver, the notification shade, Face ID, alerts, and the accessibility audit. mobile_keychain and alert accept change Simulator trust and permission state, so verify them on a throwaway Simulator (xcrun simctl create) instead.

npm run live:tools covers the app-discovery, appearance, accessibility, screen-info, and long-press tools, and asserts that platform and coordinate rejections still reject. It exercises Android in full and skips the iOS paths that would take over the Simulator with WebDriverAgent; set MOBILE_MCP_LIVE_WDA=1 to include them.

npm run live performs fast screenshots, UI-tree reads, and HOME input on both platforms. npm run live:deep uses the MCP stdio protocol to manipulate Android and iOS Settings, exercise a spare iOS boot/shutdown when available, set simulated locations, collect app logs, round-trip the iOS clipboard, override/clear the iOS status bar, change/restore Android battery and network profiles, rotate Android four times, remove a fingerprint touch, type and swipe, open https://example.com, verify screenshots and UI changes, exercise rejected inputs, and restore managed state.

Destructive app/device tools, permission changes, push, SMS, and install/uninstall need a disposable application/device fixture. The release gate does not run them against system apps.

Official references

The implementation and tool limits were checked against:

MCP tool specification for strict inputs, structured results, annotations, errors, and the client-side trust model for sensitive operations.
MCP transport specification for Streamable HTTP, loopback binding, and Origin validation against DNS rebinding.
Apple Xcode command-line tool reference and the installed xcrun simctl help for Simulator lifecycle, logs, privacy, location, push, and screenshots.
Android Debug Bridge, Logcat, and Emulator console for app state, permissions, logs, location, and emulator lifecycle.

See PLAN.md for the approved scope and release gates.

Available Tools

12 tools

mobile_boot_deviceBoot Mobile DeviceA

Idempotent

Boot an iOS Simulator or configured Android virtual device and wait until it is ready.

ParametersJSON Schema

Name	Required	Description	Default
`device`	Yes	Stable device ID returned by mobile_list_devices
`timeoutSeconds`	No

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description states that the tool waits until the device is ready, which adds behavioral context beyond the annotations (idempotentHint: true, destructiveHint: false). It does not contradict annotations. However, it could elaborate on what 'ready' means (e.g., boot completion status).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, 14-word sentence that is front-loaded with the key action and resource. No superfluous words or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is adequate for a simple boot operation but leaves open questions: What happens if boot fails? Does it throw an error? What does 'ready' mean? How long might it wait? The presence of annotations helps, but the description could be more thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50% (only 'device' has a description). The description implicitly refers to the 'device' parameter ('Boot an iOS Simulator or configured Android virtual device'), but does not mention 'timeoutSeconds' or its semantics. With low coverage, the description should compensate for the undocumented parameter but does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool boots an iOS Simulator or Android virtual device and waits until it is ready. The verb 'Boot' is specific and the resource 'device' is unambiguous. It distinguishes from siblings like mobile_launch_app (boots device vs. launches app).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is used when you need to boot a device, but provides no explicit guidance on when to use it versus alternatives. It does not mention prerequisites (e.g., device must be configured) or when not to use it. Context is implied but not fully elaborated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mobile_erase_deviceErase iOS SimulatorA

Destructive

Shut down and erase all content and settings from an iOS Simulator. Android online wipe is not supported by the official emulator console.

ParametersJSON Schema

Name	Required	Description	Default
`device`	Yes	Stable device ID returned by mobile_list_devices

Output Schema

ParametersJSON Schema

Name	Required	Description
`device`	Yes
`erased`	Yes

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark destructiveHint=true. The description adds that the tool shuts down before erasing and clarifies Android compatibility, providing useful behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences deliver the core message and a key limitation. No wasted words, though space is available for elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the single parameter, destructive annotations, and presence of output schema, the description covers the essential behavior and limitations adequately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear parameter description. The tool description does not add extra parameter-level detail, meeting the baseline without exceeding it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the action ('Shut down and erase all content and settings') and resource ('iOS Simulator'), and distinguishes from siblings like mobile_reset_app by covering full device wipe. The note about Android unsupport adds specificity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for full device wipe and alerts against Android use, but does not explicitly state when to choose this over similar tools like mobile_reset_app or mobile_shutdown_device. Guidelines are present but not comprehensive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mobile_get_logsGet Mobile App LogsA

Read-onlyIdempotent

Return bounded recent logs for one installed app. Android filters by package UID; iOS filters by the app executable.

ParametersJSON Schema

Name	Required	Description
`appId`	Yes
`device`	Yes	Stable device ID returned by mobile_list_devices
`maxLines`	No
`sinceMinutes`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`logs`	Yes
`appId`	Yes
`device`	Yes
`platform`	Yes
`truncated`	Yes

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds meaningful behavioral context: platform-specific filtering (UID vs executable) and bounded recency, which complements the annotations without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences: first states the overall purpose, second adds crucial platform-specific detail. No wasted words, front-loaded with key action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple structure (4 params, output schema exists), the description covers the core purpose and platform nuance. It could note potential log length truncation or permissions, but overall it's sufficiently complete for selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is low (25%: only device has a description). The description compensates partially by explaining that logs are 'bounded recent' (relates to maxLines and sinceMinutes) and that appId identifies the app. However, it does not detail parameter ranges, defaults, or how the platform filtering maps to parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns bounded recent logs for one installed app, with specific verb 'return' and resource 'logs'. It also distinguishes from siblings by focusing on logs for a single app, which is different from listing devices or managing app lifecycle.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when needing recent logs for a specific app, but no explicit when-not-to-use or alternative tools are mentioned. The sibling list suggests alternatives like mobile_list_devices for device info, but guidance is absent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mobile_install_appInstall Mobile AppA

DestructiveIdempotent

Install an APK on an Android Emulator or an .app directory on an iOS Simulator. Paths are confined beneath MOBILE_MCP_APP_ROOT.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`device`	Yes	Stable device ID returned by mobile_list_devices

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructive and idempotent. The description adds the behavioral trait of path confinement beneath MOBILE_MCP_APP_ROOT. It does not contradict annotations. However, it does not elaborate on what happens on install (e.g., overwrite behavior) or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no redundant information. Front-loaded with the core action. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers platform and path confinement. With no output schema, it would benefit from describing return values or success/failure indicators. However, the tool is simple and context from sibling tools fills some gaps (e.g., need to boot device first).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not explain any parameters. Schema coverage is 50% (only device has a description). The path parameter lacks any description both in schema and in the tool description, leaving confusion about format or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Install' and specifies the resources: APK on Android Emulator or .app directory on iOS Simulator. It distinguishes from sibling tools like mobile_launch_app or mobile_reset_app.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides implicit usage context (install before launching) but lacks explicit when-to-use versus alternatives like mobile_launch_app. No exclusions or prerequisites are mentioned beyond path confinement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mobile_launch_appLaunch Mobile AppB

Idempotent

Launch an installed app by iOS bundle ID or Android package name.

ParametersJSON Schema

Name	Required	Description	Default
`appId`	Yes
`device`	Yes	Stable device ID returned by mobile_list_devices

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds minimal behavioral context beyond annotations. Annotations already indicate idempotent and non-destructive. The description does not disclose error behavior (e.g., if app not found) or interaction details (e.g., foreground launch).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded, no wasted words. Efficiently communicates core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 2-parameter tool with annotations, the description is adequate. Could mention that the app must be installed or the return value, but lacks major omissions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50% (device has description, appId does not). The description adds meaning for appId (bundle ID or package name) but not for device. With moderate coverage, description provides partial compensation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Launch'), the resource ('installed app'), and how to identify it ('by iOS bundle ID or Android package name'). It distinguishes from sibling tools like mobile_install_app (install vs launch) and mobile_terminate_app (terminate vs launch).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. Does not mention prerequisites (e.g., app must be installed, device must be booted) or conditions to avoid (e.g., if app is already running).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mobile_list_devicesList Mobile DevicesA

Read-onlyIdempotent

List available iOS Simulators, running Android Emulators, and configured Android virtual devices. Physical devices are excluded.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds that physical devices are excluded, which is important behavioral context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence of 14 words that is perfectly concise with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters, no output schema, and annotations covering safety, the description fully captures what the tool does and its scope.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so schema coverage is 100%. Baseline for zero parameters is 4; no additional parameter info needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies exactly what the tool lists (iOS simulators, running Android emulators, configured Android virtual devices) and explicitly excludes physical devices. This distinguishes it clearly from sibling tools like mobile_boot_device or mobile_install_app.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use or not use this tool, but given its listing nature and sibling context, the use case is implied: to discover available devices before performing other operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mobile_reset_appReset Mobile App StateA

Destructive

Clear Android app data or uninstall an iOS app. Reinstall the iOS app with mobile_install_app afterward.

ParametersJSON Schema

Name	Required	Description	Default
`appId`	Yes
`device`	Yes	Stable device ID returned by mobile_list_devices

Output Schema

ParametersJSON Schema

Name	Required	Description
`appId`	Yes
`reset`	Yes
`device`	Yes
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare destructiveHint=true; description adds platform-specific details (clear data vs uninstall), providing useful behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with the main action; no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive reset tool with output schema present, description adequately covers platform behavior and follow-up, meeting completeness needs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50% (only device described); description adds no parameter-specific details beyond schema, failing to compensate for the gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states platform-specific actions (clear Android data, uninstall iOS) and references reinstallation for iOS, distinguishing it from mobile_install_app.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states use case (reset app state) and mentions post-action for iOS (reinstall with mobile_install_app). Could be improved by excluding when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mobile_send_pushSend iOS Simulator PushA

Send an APNs JSON payload to an installed iOS Simulator app. Android FCM has no equivalent adb command.

ParametersJSON Schema

Name	Required	Description
`appId`	Yes
`device`	Yes	Stable device ID returned by mobile_list_devices
`payload`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`appId`	Yes
`bytes`	Yes
`device`	Yes
`pushed`	Yes

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate mutating action (readOnlyHint false) and not destructive (destructiveHint false). Description adds that it sends a push payload but does not detail idempotency, side effects (e.g., replacing vs. adding to notification queue), or authentication/payload constraints. With low annotation detail, description carries burden but only partly addresses it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no redundant information. First sentence states action and target, second provides a useful cross-platform comparison. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has output schema (assumed present) and description covers purpose and platform. It references mobile_list_devices for device ID, aiding chaining. However, lacks details like APNs certificate requirement or payload format specifics. Minor gaps but sufficient for a focused tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33% (device parameter has a description). appId and payload have no description in schema, and the tool description does not elaborate on them beyond naming. Payload is described as 'APNs JSON' but no structure details. The description adds minimal value over schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it sends an APNs JSON payload to an installed iOS Simulator app. It also mentions the Android FCM has no equivalent, distinguishing it from any cross-platform tool. The verb 'send' and resource 'payload to app' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states that Android FCM has no equivalent adb command, implying this tool is iOS-only. It does not provide explicit when-not-to-use or alternative tool names, but the sibling list includes no other push tools, so the context is clear. Lacks explicit preconditions like app must be installed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mobile_set_locationSet Mobile LocationA

Idempotent

Set simulated latitude/longitude on iOS or Android. Clearing the simulated location is supported on iOS only.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`action`	Yes
`device`	Yes
`latitude`	No
`longitude`	No

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate idempotentHint=true and destructiveHint=false. The description adds platform support details (iOS/Android, clearing on iOS) but lacks information on side effects, permissions, or state changes beyond the setting action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is a single concise sentence plus a brief note, with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema (content unknown), the description is minimal. It does not explain how to specify latitude/longitude, prerequisites, or output interpretation, leaving significant gaps for a mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 0 parameters, so description cannot add parameter-level meaning. Baseline score of 4 is appropriate as per guidelines for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool sets simulated latitude/longitude on iOS or Android, specifying the verb 'Set' and resource. It also notes a platform-specific capability (clearing on iOS), distinguishing it from sibling tools like mobile_set_permission.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. It only mentions clearing support on iOS, but no context for choosing this tool over other mobile tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mobile_set_permissionSet Mobile App PermissionB

DestructiveIdempotent

Grant, revoke, or reset an allowlisted iOS Simulator privacy service; grant or revoke a declared Android runtime permission.

ParametersJSON Schema

Name	Required	Description
`appId`	Yes
`action`	Yes
`device`	Yes	Stable device ID returned by mobile_list_devices
`permission`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`appId`	Yes
`action`	Yes
`device`	Yes
`updated`	Yes
`permission`	Yes

TDQS

B3.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description adds context about platform-specific behaviors (iOS Simulator allowlisted services vs. Android runtime permissions) beyond annotations. However, it doesn't disclose side effects, prerequisites (e.g., device booted, app installed), or error conditions. Annotations already indicate mutation and destructiveness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence is concise but slightly dense due to combining two platforms. Could be split for readability, but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema (not shown), the description misses important context like behavior when the app isn't installed or the device isn't booted. With 4 required parameters and low schema coverage, more guidance is needed for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is low (25%), but the description explains the 'permission' parameter meaning (iOS vs. Android) and the 'action' parameter values (grant, revoke, reset). It adds significant value for these two parameters, though 'device' and 'appId' lack explanation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool grants, revokes, or resets mobile app permissions for both iOS Simulator and Android. It distinguishes itself from sibling tools like mobile_install_app or mobile_reset_app by focusing on permissions, but doesn't explicitly differentiate from potential sibling permission tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance provided on when to use this tool versus alternatives (e.g., mobile_reset_app for resetting app data). No preconditions or scenarios mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mobile_shutdown_deviceShut Down Mobile DeviceA

Idempotent

Shut down a running iOS Simulator or Android Emulator without deleting its data.

ParametersJSON Schema

Name	Required	Description	Default
`device`	Yes	Stable device ID returned by mobile_list_devices

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate idempotent and non-destructive behavior. The description adds that it shuts down without deleting data, which is consistent and provides additional context. No contradictions or missing behavioral details for this simple tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that efficiently conveys the purpose and key constraint. Every word earns its place with no redundancy or unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description provides complete information about what the tool does and its non-destructive nature. The annotations further support this, making the definition adequate for selecting and invoking the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage for the single required parameter 'device', which is already described as 'Stable device ID returned by mobile_list_devices'. The description does not add new meaning beyond that, so baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Shut down' and the specific targets 'iOS Simulator or Android Emulator'. It also includes the crucial constraint 'without deleting its data'. This distinguishes it from siblings like mobile_boot_device and mobile_erase_device.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when needing to stop a simulator/emulator while preserving data. It does not explicitly state when not to use or provide alternatives, but the context from sibling names like mobile_boot_device provides clear differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mobile_terminate_appTerminate Mobile AppA

Idempotent

Terminate an app by iOS bundle ID or Android package name without clearing app data.

ParametersJSON Schema

Name	Required	Description	Default
`appId`	Yes
`device`	Yes	Stable device ID returned by mobile_list_devices

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare destructiveHint=false and idempotentHint=true. The description adds that it does not clear app data, providing useful context beyond the annotations. No contradiction found.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no extraneous information. Front-loaded with the action and key constraint. Every word serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with two parameters and no output schema, the description covers the essential behavioral and parameter context. No missing information is evident.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50% (device described, appId not). The description adds meaning by specifying that appId can be an iOS bundle ID or Android package name, which helps the agent understand the parameter's usage beyond type constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (terminate an app) and the method (by iOS bundle ID or Android package name). It also specifies a key behavioral detail (without clearing app data), which distinguishes it from siblings like mobile_reset_app.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for termination without data clearance but does not explicitly state when to use or not use this tool versus alternatives. No exclusion or alternative references provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

12 tool updatesv0.2.0Jul 27, 2026
- First observedmobile_boot_device
- First observedmobile_erase_device
- First observedmobile_get_logs
- First observedmobile_install_app
- First observedmobile_launch_app
- First observedmobile_list_devices
- First observedmobile_reset_app
- First observedmobile_send_push
- First observedmobile_set_location
- First observedmobile_set_permission
- First observedmobile_shutdown_device
- First observedmobile_terminate_app

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A4/5.0

Scored 2026-07-27 16:12 across 12 tools

Disambiguation5/5

Each tool targets a distinct operation (device management, app lifecycle, permissions, location, push notifications) with no overlap. Descriptions clearly differentiate iOS and Android where needed.

Naming Consistency5/5

All tools follow the consistent pattern 'mobile_verb_noun' with snake_case. Verbs are action-oriented (list, boot, install, etc.) and noun complements are specific.

Tool Count5/5

With 12 tools, the set covers device and app lifecycle, permissions, location, and push notifications without being excessive or too sparse for the domain of mobile simulation/emulation.

Completeness4/5

The surface covers core workflows (list, boot, install, launch, terminate, reset, logs, permissions, location, push, erase). Minor gaps like device details or screenshots are not critical but would enhance completeness.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

mobilerun
io.github.droidrun
Control real Android and iOS devices with LLM agents — tap, swipe, type, automate flows.
Testing & QA Tools App Automation
38,854
Ramus AndroidOAuth
dev.ramus
Disposable cloud Android emulators for coding agents: run an APK or PR build, tap, type, screenshot.
CI/CD & DevOps Testing & QA Tools
1
OmniDebugLink AOAuth
dev.omnidebuglink.api
Drive real devices from your AI Coding tool. Embed a client SDK (Unity, Godot, Flutter, iOS/macOS, Android, React Native, Web) in your app, then capture screenshots, traverse the UI tree, inject taps and key events, and run automated test tasks on the physical device over a secure relay.
Coding Agents Developer Tools
61
LimrunOAuth
com.limrun
Cloud iOS simulators and Android emulators your agent can create, drive, and throw away.
Cloud Platforms Testing & QA Tools Virtualization
1

Related MCP Servers

iOS Automation MCP Server
App Automation Testing & QA Tools Developer Tools
iHackSubhodip
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that enables AI assistants to interact with iOS simulators, perform accessibility testing, manage apps, and automate complex iOS workflows.
Updated a year ago (2025-07-26 12:41 UTC)
32
Apache 2.0
Simulator MCP
Developer Tools Testing & QA Tools App Automation
992429169
F
license
Not graded
quality
D
maintenance
Enables AI to control iOS simulators through the MCP protocol. Supports device management, UI automation, and network interception including screenshot capture, text input, and HTTP request mocking.
Updated 6 months ago (2026-04-14 07:53 UTC)
-
simctl-mcp
Developer Tools Virtualization Testing & QA Tools
ambar
A
license
B
quality
D
maintenance
A Model Context Protocol server implementation for iOS Simulator control, providing tools for device management, app operations, permissions, system features, and certificate handling.
Updated a year ago (2025-08-22 05:31 UTC)
29
13 npm
20
MIT
MCP Testing Server
API Testing Browser Automation Testing & QA Tools
siddikshaikh-haptiq
F
license
Not graded
quality
D
maintenance
A local testing tool for APIs, web browsers, and phone UI using the Model Context Protocol.
Updated a year ago (2025-11-20 12:41 UTC)
-

Mobile Simulator & Emulator MCP

Requirements

Quick start

Configure an MCP client

HTTP mode (--listen)

Recommended agent workflow

Example requests

Tools

Device IDs

Configuration

Security model

Limits

Troubleshooting

mobile_doctor reports a missing Android command

iOS UI calls time out on first use

App installation is rejected

A deep link scheme is rejected

A device ID is rejected

Development and release checks

Official references

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

HTTP mode (`--listen`)

`mobile_doctor` reports a missing Android command