Skip to main content
Glama
Sign In
MCP Appium

MCP Appium

by Bhaswanth-Bandlamudi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

appium_session_management

Destructive

Create, attach to, detach, delete, list, and select Appium sessions to manage mobile test automation connections and switch the active session.

Instructions

Manage Appium sessions. Use action=create to start a session, attach to connect to an existing one, detach to forget an attached session, delete to stop one, list to see all active sessions, or select to switch the active session.

Input Schema

NameRequiredDescriptionDefault
actionYescreate: Create a new Appium session. DEFAULT MODE (no remoteServerUrl): use unless the user explicitly provides a server URL. - Drivers run embedded inside this MCP server; no separate Appium process is needed. - Use select_device tool FIRST to discover devices. Ask for platform/device if unknown; do not assume a platform. - For iOS simulators, run prepare_ios_simulator before creating the session. - Call appium_session_management action=create with the selected platform and any returned capabilitiesHint serialized as capabilities. - Do NOT pass remoteServerUrl for local/embedded mode. NEVER invent a localhost URL. REMOTE SERVER MODE (only when user explicitly provides a URL): - Skip local device selection and preparation; do not call select_device. - Infer platform and device type from the request when possible; ask if unclear. - Use platform=general for non-Android/iOS drivers (Windows, macOS, custom); capabilities pass through without platform defaults. - Call appium_session_management action=create with platform, remoteServerUrl, and the requested capabilities. - Example: "create an iOS session at http://localhost:4723" means platform=ios and remoteServerUrl=http://localhost:4723; do not discover local devices. attach: connect to an existing remote Appium session without taking ownership of its lifecycle. Requires remoteServerUrl and sessionId; capabilities are fetched from the remote server. detach: remove an attached session from MCP without deleting the real remote session. Defaults to the active session. delete: delete a session and clean up resources. Defaults to the active session. list: list managed sessions with active flag, ownership, and current context. select: set sessionId as the active session for subsequent calls; requires sessionId.
platformNoRequired for create. For local sessions, match the platform selected via select_device. For remote sessions, infer from the request; general supports non-Android/iOS drivers (Windows, macOS, custom) and requires remoteServerUrl.
sessionIdNoRequired for attach and select: the existing session to connect to or activate. For delete: session to delete. For detach: attached session to forget without stopping it. Delete/detach default to the active session when omitted.
capabilitiesNoOptional W3C capabilities as a JSON string, e.g. '{"appium:app":"/path/to/app","appium:platformVersion":"17.0"}'. Create: overrides defaults for ios/android; passed through as-is for general. Common keys: appium:app, appium:deviceName, appium:udid, appium:platformVersion, appium:bundleId. When using capabilitiesHint from a preparation tool, serialize the full object to JSON; preserve boolean and numeric values. Attach: optional fallback values (e.g. '{"platformName":"iOS"}'); capabilities fetched from the server take precedence.
confirmTokenNocreate only: required on the repeat call when capabilities request fullReset (CONFIRMATION REQUIRED).
remoteServerUrlNoRemote Appium server URL for create or attach (e.g. http://localhost:4723). Omit to use local server for create.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.99.3

TDQS

A4/5.0
Behavior4/5

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

The description adds meaningful lifecycle distinctions beyond the annotations, especially that attach does not take ownership and detach removes a session from MCP without deleting the real remote session. This complements destructiveHint=true by clarifying which actions actually destroy resources.

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 front-loaded with the general purpose and then compactly maps each action to its effect. Every clause contributes to selecting the correct action, with no redundant wording.

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 six-parameter, destructive, multi-action session tool, the description provides adequate high-level action semantics, while the very rich schema carries the detailed create/attach/capability behavior. The top-level description itself does not surface the local-versus-remote create nuance, but that is well covered in structured schema descriptions.

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%, so parameter meanings are already documented in detail, including remote/local create behavior and confirmation requirements. The description only restates the action values and does not add parameter-level meaning beyond the schema.

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 clearly identifies session lifecycle management and enumerates all six actions, so the resource and operations are unambiguous. It does not explicitly contrast itself with sibling tools, keeping it below a 5.

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?

It gives direct action-selection guidance: create to start, attach for existing sessions, detach to forget without deleting, delete to stop, list to inspect, and select to activate. It lacks explicit when-not-use conditions or alternatives outside this tool, but the internal action routing is clear.

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