Skip to main content
Glama

Swipe

phone_swipe

Drags a finger between two screen coordinates to perform custom swipes and gestures that standard scrolling cannot handle.

Instructions

Drag a finger from one point to another (screenshot pixels). For gestures that scrolling does not cover.

Input Schema

NameRequiredDescriptionDefault
x1Yes
x2Yes
y1Yes
y2Yes
serialNoWhich device to use. Only needed when several are connected.
duration_msNoDefault 300.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations, the description must carry the behavioral burden. It discloses that this injects a finger-drag gesture and that coordinates are screenshot pixels, but it does not state that the gesture can alter UI state, what happens on failure, or what the call returns.

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?

Two sentences, front-loaded with the action and coordinate frame, followed by the usage condition. There is no redundant restatement of the tool name or title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter device-input tool with no annotations and no output schema, the description is somewhat under-specified. It covers the core action and coordinate unit, but not the precise parameter roles, device selection, gesture duration, or post-gesture result.

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 only 33%, so the description should compensate. It clarifies that the four required numbers are start/end points in screenshot pixels, but it does not map x1/y1 vs x2/y2 explicitly or mention duration_ms and serial, which the schema partially covers.

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 action (drag a finger from one point to another) and fixes the coordinate system as screenshot pixels. It also distinguishes itself from phone_scroll by saying it is for gestures scrolling does not cover.

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 explicitly names scrolling as the alternative and gives the condition that selects this tool over scrolling. However, it does not mention other sibling alternatives such as phone_tap for simple taps, so the guidance is clear but not exhaustive.

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