Skip to main content
Glama

Swipe Screen

mobile_swipe_on_screen
Destructive

Perform swipe gestures on mobile device screens to navigate apps, scroll content, or trigger actions by specifying direction and coordinates.

Instructions

Swipe on the screen

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
deviceYesThe device identifier to use. Use mobile_list_available_devices to find which devices are available to you.
directionYesThe direction to swipe
xNoThe x coordinate to start the swipe from, in pixels. If not provided, uses center of screen
yNoThe y coordinate to start the swipe from, in pixels. If not provided, uses center of screen
distanceNoThe distance to swipe in pixels. Defaults to 400 pixels for iOS or 30% of screen dimension for Android

Implementation Reference

  • The handler function for the swipe_on_screen tool. It requires a device to be selected, then calls the appropriate swipe method on the Robot instance based on whether coordinates are provided.
    async ({ direction, x, y, distance }) => {
    	requireRobot();
    
    	if (x !== undefined && y !== undefined) {
    		// Use coordinate-based swipe
    		await robot!.swipeFromCoordinate(x, y, direction, distance);
    		const distanceText = distance ? ` ${distance} pixels` : "";
    		return `Swiped ${direction}${distanceText} from coordinates: ${x}, ${y}`;
    	} else {
    		// Use center-based swipe
    		await robot!.swipe(direction);
    		return `Swiped ${direction} on screen`;
    	}
    }
  • Zod input schema for the swipe_on_screen tool parameters: required direction, optional x, y, distance.
    {
    	direction: z.enum(["up", "down", "left", "right"]).describe("The direction to swipe"),
    	x: z.number().optional().describe("The x coordinate to start the swipe from, in pixels. If not provided, uses center of screen"),
    	y: z.number().optional().describe("The y coordinate to start the swipe from, in pixels. If not provided, uses center of screen"),
    	distance: z.number().optional().describe("The distance to swipe in pixels. Defaults to 400 pixels for iOS or 30% of screen dimension for Android"),
    },
  • src/server.ts:341-363 (registration)
    Registration of the 'swipe_on_screen' tool (note: queried name was 'mobile_swipe_on_screen' but this is the matching swipe tool) using the custom 'tool' helper which calls server.tool.
    	"swipe_on_screen",
    	"Swipe on the screen",
    	{
    		direction: z.enum(["up", "down", "left", "right"]).describe("The direction to swipe"),
    		x: z.number().optional().describe("The x coordinate to start the swipe from, in pixels. If not provided, uses center of screen"),
    		y: z.number().optional().describe("The y coordinate to start the swipe from, in pixels. If not provided, uses center of screen"),
    		distance: z.number().optional().describe("The distance to swipe in pixels. Defaults to 400 pixels for iOS or 30% of screen dimension for Android"),
    	},
    	async ({ direction, x, y, distance }) => {
    		requireRobot();
    
    		if (x !== undefined && y !== undefined) {
    			// Use coordinate-based swipe
    			await robot!.swipeFromCoordinate(x, y, direction, distance);
    			const distanceText = distance ? ` ${distance} pixels` : "";
    			return `Swiped ${direction}${distanceText} from coordinates: ${x}, ${y}`;
    		} else {
    			// Use center-based swipe
    			await robot!.swipe(direction);
    			return `Swiped ${direction} on screen`;
    		}
    	}
    );
  • Robot interface defines the swipe(direction) and swipeFromCoordinate(x,y,direction,distance?) methods called by the tool handler.
     * Swipe in a direction.
     */
    swipe(direction: SwipeDirection): Promise<void>;
    
    /**
     * Swipe from a specific coordinate in a direction.
     */
    swipeFromCoordinate(x: number, y: number, direction: SwipeDirection, distance?: number): Promise<void>;
  • Implementation of swipe(direction) in AndroidRobot class, calculates start/end coordinates based on direction and screen size, executes via adb shell input swipe.
    public async swipe(direction: SwipeDirection): Promise<void> {
    	const screenSize = await this.getScreenSize();
    	const centerX = screenSize.width >> 1;
    
    	let x0: number, y0: number, x1: number, y1: number;
    
    	switch (direction) {
    		case "up":
    			x0 = x1 = centerX;
    			y0 = Math.floor(screenSize.height * 0.80);
    			y1 = Math.floor(screenSize.height * 0.20);
    			break;
    		case "down":
    			x0 = x1 = centerX;
    			y0 = Math.floor(screenSize.height * 0.20);
    			y1 = Math.floor(screenSize.height * 0.80);
    			break;
    		case "left":
    			x0 = Math.floor(screenSize.width * 0.80);
    			x1 = Math.floor(screenSize.width * 0.20);
    			y0 = y1 = Math.floor(screenSize.height * 0.50);
    			break;
    		case "right":
    			x0 = Math.floor(screenSize.width * 0.20);
    			x1 = Math.floor(screenSize.width * 0.80);
    			y0 = y1 = Math.floor(screenSize.height * 0.50);
    			break;
    		default:
    			throw new ActionableError(`Swipe direction "${direction}" is not supported`);
    	}
    
    	this.adb("shell", "input", "swipe", `${x0}`, `${y0}`, `${x1}`, `${y1}`, "1000");
    }
Behavior3/5

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

The description adds no behavioral context beyond what annotations provide. The destructiveHint: true annotation already indicates this is a potentially destructive operation, but the description doesn't elaborate on what might be destroyed (e.g., UI state, navigation) or any other behavioral traits like performance characteristics or side effects. However, it doesn't contradict the annotation.

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

Conciseness4/5

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

The description is extremely concise at just three words, which is appropriately brief for a simple action. However, this brevity comes at the cost of being under-specified rather than efficiently informative, as it lacks necessary context that would make it truly helpful.

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

Completeness2/5

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

For a destructive mobile interaction tool with no output schema, the description is incomplete. It doesn't explain what happens after the swipe (navigation effects, state changes), doesn't mention the mobile testing context implied by sibling tools, and provides insufficient guidance for proper use despite the tool having multiple parameters and being marked as destructive.

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?

With 100% schema description coverage, the input schema fully documents all 5 parameters including their purposes, defaults, and constraints. The description adds no additional parameter semantics beyond what's already in the structured schema, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Swipe on the screen' is a tautology that merely restates the tool name/title without adding meaningful specificity. It doesn't distinguish this swipe action from other mobile interaction tools like mobile_click_on_screen_at_coordinates or mobile_long_press_on_screen_at_coordinates, nor does it clarify what resource or context this swipe operates on.

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

Usage Guidelines2/5

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

No guidance is provided about when to use this tool versus alternatives. While the input schema mentions using mobile_list_available_devices to find devices, the description itself offers no context about appropriate use cases, prerequisites, or distinctions from sibling tools like mobile_double_tap_on_screen or mobile_press_button.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/EmpathySlainLovers/MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server