Skip to main content
Glama

Swipe the screen

swipe

Drag from one Android screen coordinate to another to scroll lists or dismiss cards; set duration to control gesture speed.

Instructions

Swipe from (x1, y1) to (x2, y2) (input swipe X1 Y1 X2 Y2 [duration_ms]), e.g. to scroll a list or dismiss a card. duration_ms is the gesture time in milliseconds (device default 300 when omitted); a longer duration drags more slowly. Coordinates are device pixels; screenshot afterwards to verify the result.

Input Schema

NameRequiredDescriptionDefault
x1YesStart X in device pixels (non-negative integer).
x2YesEnd X in device pixels (non-negative integer).
y1YesStart Y in device pixels (non-negative integer).
y2YesEnd Y in device pixels (non-negative integer).
deviceNoDevice serial from list_devices; optional when exactly one device is connected.
duration_msNoGesture duration in milliseconds; omit for the device default (300 ms).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false); the description adds that the default duration is 300 ms on omission, that longer durations drag more slowly, and that the agent should screenshot afterwards to verify. It does not discuss failure modes or permission needs, which is a minor gap for a gesture 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?

One dense, front-loaded sentence: the signature comes first, followed by use examples, duration semantics, units, and a verification tip. Every clause adds operative information and nothing is padding.

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?

There is no output schema, and the description handles this by pointing to screenshot for verification, while units, defaults, and the optional device parameter are covered in the schema. What is missing is any statement of what a failed or out-of-bounds swipe does, a small gap for a 6-parameter gesture 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?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine semantics beyond the schema: duration as a speed control ('a longer duration drags more slowly') and the default-300 behaviour in context. It reiterates pixel units rather than expanding on them, keeping it out of 5 territory.

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?

States a specific verb and resource ('Swipe from (x1, y1) to (x2, y2)') and even shows the underlying adb form, so the agent knows exactly which gesture is performed. It is trivially distinguishable from siblings like tap, key_event, or shell.

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?

Gives concrete usage context ('to scroll a list or dismiss a card'), which tells the agent when this gesture is appropriate. It does not state exclusions or explicitly contrast with tap/key_event for other navigation cases, so it stops short of a 5.

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