Skip to main content
Glama
appium

MCP Appium

Official
by appium
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

appium_app_lifecycle

Manage mobile app states: install, uninstall, activate, terminate, clear data, and handle deep links for iOS and Android testing.

Instructions

Manage app lifecycle, installation, state, data, and deep links.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoAndroid package or iOS bundle ID; takes precedence over name.
urlNoURL for deep_link (e.g. https://example.com or myapp://path).
nameNoHuman-readable app name resolved to an ID; alternative to id.
pathNoApp file path or HTTP(S) URL; required for install. Embedded URL downloads require ALLOW_REMOTE_APP_URLS=true (default). Remote sessions resolve app inputs on the remote Appium server.
actionYesactivate: foreground app; terminate: stop app; is_installed: check installation; clear: clear app data without uninstalling (all require id or name). install: requires path. uninstall: requires id/name; Android keepData is optional. list: optional iOS applicationType. query_state: get state 0=not installed,1=not running,2=background suspended,3=background,4=foreground (requires id or name). background: send foreground app to background; optional seconds (default 5). deep_link: requires url; id/name is optional.
secondsNoBackground duration; default 5. Use -1 to remain in background.
keepDataNoAndroid uninstall: preserve app data and cache.
sessionIdNoSession ID; defaults to the active session.
waitForLaunchNoAndroid deep_link: wait for the activity to return; default true.
applicationTypeNoiOS list filter: User (default) or System.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.95.0
    • changedInput schema / properties / path / description
      Previous value: -"App file path; required for install."New value: +"App file path or HTTP(S) URL; required for install. Embedded URL downloads require ALLOW_REMOTE_APP_URLS=true (default). Remote sessions resolve app inputs on the remote Appium server."
    • changedInput schema / properties / sessionId / description
      Previous value: -"Session ID to target. If omitted, uses the active session."New value: +"Session ID; defaults to the active session."
  2. First observedv1.92.11

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already signal non-read-only and open-world behavior, and the description adds no further behavioral disclosure. It does not mention that clear/uninstall destroy data, install may fetch remote URLs, or deep_link can wait for activity launch. No contradiction exists, but the description carries little transparency weight.

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?

The description is a single efficient sentence and lists the main capability areas without filler. It is heavily front-loaded, though the word 'Manage' adds little beyond the action-category list.

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?

With 10 parameters, 10 distinct actions, and no output schema, a one-line description is not enough for an agent to confidently select and invoke the tool. The schema fills in action details, but the description lacks context about destructive operations, prerequisites, and when this tool is the right choice.

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 100%, so the schema already explains every parameter. The tool description adds no parameter-specific meaning, which is acceptable at the baseline but not a contributor.

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?

The description names concrete domains—lifecycle, installation, state, data, and deep links—so an agent can tell this is the app-level management tool rather than UI, session, or device-control tools. The verb 'Manage' is broad, but the appended resource list gives useful specificity.

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?

There is no guidance on when to use this tool versus sibling tools like appium_mobile_device_control or appium_session_management. No exclusions, alternatives, or selection criteria are stated; the agent must infer usage from the action enum.

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

Deploy Server

Other Tools