Skip to main content
Glama

gesture-tap

Tap buttons, links, or any tappable element on iOS simulators, Android emulators, or Chromium apps using normalized coordinates. Set clickCount to 2 for a double-tap or double-click.

Instructions

Press the device screen (iOS simulator or physical device, Android emulator, or Chromium app) at normalized coordinates: x and y are fractions of screen width and height in 0.0–1.0 (not pixels). Sends a Down event followed by an Up event at the same point. For Chromium, this dispatches a CDP mouse-press/release on the renderer. Set clickCount: 2 for a double-tap / double-click — the taps are dispatched as one gesture with proper click counting, which two separate tap calls cannot guarantee. Use when you need to tap a button, link, or any tappable element on the screen. Returns { tapped: true, timestampMs }. On physical iOS, reactivated: true = app was re-fronted; re-describe. Fails if the simulator-server / emulator backend / Chromium CDP is not reachable for the given device. On a physical iPhone use describe; native-describe-screen is simulator-only. Before tapping, determine the correct coordinates by using discovery tools — pick by platform: iOS / Android use describe, native-describe-screen, or debugger-component-tree; Chromium uses describe (the DOM walker), since the native and RN-specific discovery tools don't apply. More information in argent-device-interact skill

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xYesNormalized horizontal position 0.0–1.0 (left=0, right=1), not pixels
yYesNormalized vertical position 0.0–1.0 (top=0, bottom=1), not pixels
udidYesTarget device id from `list-devices` (iOS UDID, Android serial, or Chromium id).
clickCountNoNumber of taps/clicks dispatched as ONE multi-tap gesture (2 = double-tap / double-click). The taps land inside the OS double-tap window; on Chromium each click carries an escalating CDP clickCount so dblclick actually fires; on physical iOS 2 is the native double-tap and higher counts land as separate taps. Default 1.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changedv0.24.0
    • changedInput schema / properties / clickCount / description
      Previous value: -"Number of taps/clicks dispatched as ONE multi-tap gesture (2 = double-tap / double-click). The taps land inside the OS double-tap window; on Chromium each click carries an escalating CDP clickCount so dblclick actually fires. Default 1."New value: +"Number of taps/clicks dispatched as ONE multi-tap gesture (2 = double-tap / double-click). The taps land inside the OS double-tap window; on Chromium each click carries an escalating CDP clickCount so dblclick actually fires; on physical iOS 2 is the native double-tap and higher counts land as separate taps. Default 1."
  2. Changed1 schema field changedv0.16.0
    • addedInput schema / properties / clickCount
      Added value: +{
      +  "description": "Number of taps/clicks dispatched as ONE multi-tap gesture (2 = double-tap / double-click). The taps land inside the OS double-tap window; on Chromium each click carries an escalating CDP clickCount so dblclick actually fires. Default 1.",
      +  "maximum": 10,
      +  "minimum": 1,
      +  "type": "integer"
      +}
  3. First observedv0.15.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It details the Down/Up event sequence, Chromium CDP behavior, clickCount semantics across platforms, physical iOS reactivation behavior, return values, and failure conditions. This is far more transparent than typical tool descriptions.

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?

Although the description is long, it is dense with necessary operational detail and every sentence adds value. The core action and coordinate system are front-loaded, followed by platform behavior, usage guidance, return values, and failure modes. The length is justified by the tool's complexity.

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?

The description is complete for a tool of this complexity: it covers coordinate interpretation, event semantics, double-tap behavior, platform-specific execution, return payload, failure modes, and how to choose discovery tools. With no output schema or annotations, this level of detail is exactly what an agent needs to invoke the tool correctly.

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?

The input schema already covers all 4 parameters with descriptions, so baseline is 3. The description adds meaningful semantics beyond the schema: it explains normalized coordinates, clickCount behavior for double-tap/double-click, cross-platform differences, and the guarantee of proper click counting. This raises it above baseline.

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: it presses the screen at normalized coordinates and sends a Down/Up event to tap a button, link, or tappable element. It clearly differentiates tap behavior from multi-tap and provides platform-specific semantics, making it distinguishable from sibling gesture tools like gesture-swipe or gesture-custom.

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 description explicitly says when to use the tool ('Use when you need to tap a button, link, or any tappable element') and gives strong platform-specific guidance on which discovery tools to use before tapping. It does not explicitly name sibling alternatives like gesture-swipe or gesture-drag, but the usage context is clear enough for an agent to select this tool correctly.

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

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/software-mansion/argent'

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