mobile-debug-mcp

Overview Schema Source Related Servers Discussions Admin

swipe

Dispatch a swipe gesture on Android or iOS using start and end coordinates and a duration. Simulate scrolling, paging, or drag interactions during mobile app testing, with optional platform and device targeting.

Instructions

Purpose: Dispatch a swipe gesture on Android or iOS.

Inputs:

start and end coordinates
duration
platform/deviceId (optional)

Output Structure:

action_id, timestamp (ISO 8601), action_type
lifecycle_state: post-dispatch lifecycle state (pending_verification or failed)
source_module: runtime source of the action envelope
target.selector = { x1, y1, x2, y2, duration }
success = true when the swipe was dispatched
failure_code/retryable when dispatch fails
ui_fingerprint_before/ui_fingerprint_after when available

Recommended Usage:

Determine swipe coordinates
Call swipe
If needed, wait for transition using wait_for_*
Verify with expect_screen or expect_element_visible when a deterministic outcome is expected

Verification Guidance:

Swipe outcomes are less predictable; choose the most specific verifier available for the intended effect
Follow RESOLVE → ACT → WAIT (if needed) → EXPECT
Do not use wait_for_* alone as final verification when an applicable expect_* tool exists

Failure Handling:

TIMEOUT → retry once
UNKNOWN → capture a snapshot and stop

Conditional input: optionally supply expectedState { snapshotSessionId, snapshotRevision, timeoutMs? } from a successful get_ui_tree on the same explicit platform/deviceId. A fresh normalized UI-tree check runs immediately before input, even with verification disabled. PRECONDITION_FAILED or PRECONDITION_UNAVAILABLE means no input was dispatched; inspect condition evidence and re-observe before deciding what to do next. Compact failures summarize the fresh condition evidence; use get_interaction_diagnostics with the returned diagnostics reference for the retained UI tree. This is not atomic with OS input delivery. Compact results summarize observations, condition trees, state deltas and readiness probe evidence within a byte budget. Use get_interaction_diagnostics with the returned diagnostics session_id/result_id to retrieve the original result without replaying input. Debug output is unchanged. Results include device_readiness with timestamped device blocker evidence. Android reports supported power/keyguard signals; iOS signals may be unknown or explicitly unsupported. Launch/input dispatch success does not establish app visibility or input readiness. No automatic unlock or wake is performed.

Input Schema

Name	Required	Description	Default
`x1`	Yes	Start X coordinate
`x2`	Yes	End X coordinate
`y1`	Yes	Start Y coordinate
`y2`	Yes	End Y coordinate
`deviceId`	No	Device Serial/UDID. Defaults to connected/booted device.
`duration`	Yes	Duration in ms
`platform`	No	Platform to swipe on (android or ios)
`responseMode`	No		debug
`expectedState`	No
`actionTimeoutMs`	No	Dispatch budget in milliseconds, clamped to 100–30000.
`verificationMode`	No		full
`verificationTimeoutMs`	No	Light observation budget in milliseconds, clamped to 100–60000.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv0.34.0Oct 31, 2026

addedInput schema / allOf

Added value: +[
+  {
+    "if": {
+      "required": [
+        "expectedState"
+      ]
+    },
+    "then": {
+      "properties": {
+        "deviceId": {
+          "minLength": 1,
+          "not": {
+            "enum": [
+              "booted",
+              "default"
+            ]
+          },
+          "pattern": "\\S",
+          "type": "string"
+        },
+        "platform": {
+          "enum": [
+            "android",
+            "ios"
+          ]
+        }
+      },
+      "required": [
+        "platform",
+        "deviceId"
+      ]
+    }
+  }
+]

addedInput schema / properties / actionTimeoutMs

Added value: +{
+  "description": "Dispatch budget in milliseconds, clamped to 100–30000.",
+  "type": "integer"
+}

addedInput schema / properties / expectedState

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "snapshotRevision": {
+      "maximum": 9007199254740991,
+      "minimum": 1,
+      "type": "integer"
+    },
+    "snapshotSessionId": {
+      "minLength": 1,
+      "type": "string"
+    },
+    "timeoutMs": {
+      "default": 15000,
+      "maximum": 60000,
+      "minimum": 100,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "snapshotSessionId",
+    "snapshotRevision"
+  ],
+  "type": "object"
+}

addedInput schema / properties / responseMode

Added value: +{
+  "default": "debug",
+  "enum": [
+    "compact",
+    "debug"
+  ],
+  "type": "string"
+}

addedInput schema / properties / verificationMode

Added value: +{
+  "default": "full",
+  "enum": [
+    "none",
+    "light",
+    "full"
+  ],
+  "type": "string"
+}

addedInput schema / properties / verificationTimeoutMs

Added value: +{
+  "description": "Light observation budget in milliseconds, clamped to 100–60000.",
+  "type": "integer"
+}

First observedv0.31.0Jul 29, 2026

TDQS

A4.2/5.0

Behavior5/5

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

With no annotations supplied, the description carries the full behavioral burden and does so thoroughly: it discloses output fields and lifecycle states, that PRECONDITION_FAILED means no input was dispatched, that the operation 'is not atomic with OS input delivery', that no automatic unlock or wake occurs, and per-platform device_readiness limitations. It also gives failure-code handling (TIMEOUT → retry once, UNKNOWN → snapshot and stop), which is exactly the kind of context annotations would otherwise provide.

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

Conciseness3/5

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

It is well-structured with labeled sections and front-loads the purpose, but it is long and the compact-results and diagnostics paragraphs are dense and partially repetitive ('This is not atomic with OS input delivery' and the readiness caveats sit in an undifferentiated trailing block). Several sentences could be tightened without losing information.

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 12-parameter mutation-style gesture tool with no annotations and no output schema, the description covers what is needed: return shape, lifecycle/verification states, failure codes and retry policy, precondition semantics, and platform-specific readiness limits. An agent could invoke and interpret this tool correctly from the description alone.

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 75%, and the description meaningfully extends the undocumented parts: expectedState is explained as a conditional input derived from a get_ui_tree snapshot with same-platform/deviceId requirements and a fresh pre-dispatch UI-tree check, and responseMode is explained via the compact-results/diagnostics-session paragraph. It does not explicitly explain verificationMode's none/light/full values or actionTimeoutMs/verificationTimeoutMs budgets, leaving those to 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 opening line states a specific verb and resource: 'Dispatch a swipe gesture on Android or iOS', which is immediately distinguishable from siblings like tap, press_back, and scroll_to_element. It stops short of explicitly contrasting swipe with scroll_to_element or tap for gesture-style interactions, so it is clear but not maximally differentiating.

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 'Recommended Usage' section gives an explicit ordered workflow (determine coordinates → swipe → wait_for_* → expect_*) and the verification guidance names concrete alternatives ('Do not use wait_for_* alone as final verification when an applicable expect_* tool exists'). What is missing is a when-not-to-use clause distinguishing swipe from scroll_to_element or tap for similar gestures.

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

Deploy Server

swipe

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools