Skip to main content
Glama
MCP Appium

MCP Appium

appium_gesture

Perform touch gestures such as tap, double tap, long press, scroll, swipe, pinch zoom, and back navigation to automate Android and iOS app interactions.

Instructions

Perform a touch gesture. Use 'action' to choose: tap, double_tap, long_press, scroll, swipe, pinch_zoom, scroll_to_element, back. Choose scroll vs swipe by intent: scroll to browse content in a list or feed; swipe to dismiss, switch screens, navigate carousels, or pull-to-refresh (speed=fast). For drag-and-drop use appium_drag_and_drop. For custom multi-touch use appium_perform_actions.

Input Schema

NameRequiredDescriptionDefault
xNoX pixel coordinate, paired with y: tap location, pinch center, or scroll/swipe start (requires endX/endY). elementUUID overrides x/y for tap/double_tap/long_press/pinch_zoom.
yNoY pixel coordinate, paired with x; same action meanings and elementUUID precedence as x.
endXNoEnding X coordinate in pixels for scroll/swipe; requires x, y, endY.
endYNoEnding Y coordinate in pixels for scroll/swipe; requires x, y, endX.
scaleNoRequired for pinch_zoom: <1 zooms out, >1 zooms in (e.g. 0.5 or 2 for 2x).
speedNoSwipe only. slow: deliberate drag; normal: default navigation speed; fast: flick without an initial hold. Use fast for pull-to-refresh and other velocity-sensitive interfaces.
actionYestap/double_tap/long_press: requires elementUUID or both x/y. scroll/swipe: requires direction or x/y/endX/endY. pinch_zoom: requires scale (<1 out, >1 in). scroll_to_element: requires strategy/selector; direction up/down (default down). Stops on a match, unchanged page source, or maxScrollAttempts. Adjust distance with scrollDistance or scrollDistancePreset. back: system back navigation.
durationNoDuration in milliseconds. long_press defaults to 2000 (range 500–10000); scroll defaults to 800. For swipe, prefer speed unless a custom movement duration is needed. For W3C swipe, overrides movement time; speed still sets the initial hold. Ignored by iOS native mobile: swipe (direction, no elementUUID, speed != fast).
selectorNoLocator selector value. Required for: scroll_to_element.
strategyNoRequired for scroll_to_element. Prefer accessibility id > id > platform-native (iOS: -ios predicate string / -ios class chain; Android: -android uiautomator) > xpath (last resort: slow/brittle). name is legacy; class name may match multiple elements; css selector is webview-only. Same priorities as appium_find_element.
velocityNoPinch velocity in scale factor per second. Default 2.2. Used by pinch_zoom.
directionNoDirection for scroll/swipe. Coordinates are calculated from the screen or element bounds. Provide either direction or custom coordinates (x, y, endX, endY); direction takes precedence if both are given. For scroll_to_element, use up/down; default down.
sessionIdNoSession ID; defaults to the active session.
elementUUIDNoElement UUID for tap, double_tap, long_press, or pinch_zoom; overrides x/y for these actions. For scroll/swipe with direction, coordinates are calculated relative to this element instead of the whole screen.
scrollDistanceNoscroll_to_element only: vertical swipe distance fraction (0.05–1). Ignored when scrollDistancePreset is set. Default 0.45 when neither option is supplied.
maxScrollAttemptsNoscroll_to_element only: maximum scroll attempts after the initial lookup fails. Default 10.
scrollDistancePresetNoscroll_to_element only: small is a light nudge (0.25), medium is 0.45, large is the full default swipe (1). Overrides scrollDistance when set.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.99.3

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false and openWorldHint=false, so the safety profile is clear. The description adds action-level intent such as browse versus dismiss versus pull-to-refresh, but it does not describe side effects, waits, or failure behavior beyond what the schema already covers.

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 three tight sentences, front-loaded with the core action and followed by action selection and sibling routing guidance. It contains no filler and does not redundantly restate the long schema.

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 17-parameter gesture tool, the description provides the high-level action model and sibling routing while the schema carries the detailed mechanics. It is nearly complete, though a complex eight-action tool could briefly mention session or element-precedence behavior at a high level.

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 100% and every parameter is documented in detail, so the description does not need to repeat coordinate, duration, or locator mechanics. It does add useful action-selection semantics that the schema does not fully capture, especially scroll versus swipe intent.

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 states a specific verb and resource, then enumerates the supported touch actions. It also distinguishes this tool from appium_drag_and_drop and appium_perform_actions, so an agent can route correctly without opening the schema.

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

Usage Guidelines5/5

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

It explicitly explains when to use scroll versus swipe by intent and names the two sibling alternatives for drag-and-drop and custom multi-touch. The pull-to-refresh speed hint further reduces ambiguity.

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