Skip to main content
Glama

Robot Actions — Remote Device Control

by com.robotactions.test
OverviewDiscussionsAdmin

device_pinch

Two-finger pinch-to-zoom centred at (x,y) on an Android device. scale > 1 zooms IN (fingers spread), scale < 1 zooms OUT (fingers converge); ~2 doubles, ~0.5 halves. Both fingers ride a VERTICAL axis through the centre, so the centre governs where they land: put it on the content you want to zoom, ideally the middle third of the screen. A centre near the top or bottom leaves no room — the span is squeezed to fit the content area and the zoom comes out weak or does nothing. Fingers are kept clear of the status and navigation bars; a finger in the status bar pulls down the notification shade instead of touching the app. Bottom sheets, dialogs and cards are app UI and cannot be detected here: if one covers the lower half, centre the pinch above it or the sheet swallows the gesture. The reply reports the finger endpoints and span actually used — if the screen did not change, check those before retrying. Coordinates are PHYSICAL pixels — same as the bounds in device_page_source.Pass input="hid" to require the virtual touchscreen: the gesture then reaches the app as real kernel input and fails loudly instead of silently falling back to injected input. That strict path used to be device_uhid_pinch, which stays callable under its old name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xYesPinch centre X
yYesPinch centre Y
udidYesDevice serial number (UDID)
inputNoInput path. 'auto' (default) prefers the virtual touchscreen and falls back to injected input. 'hid' requires the virtual touchscreen and fails if the device does not provide one — use it when the gesture must be real kernel input or must fail loudly.
scaleYesEnd/start finger-separation ratio: >1 zoom in, <1 zoom out (0.2-5)
durationNoGesture duration in ms (default: 300)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / input / description
      Previous value: -"Input path. 'auto' (default) prefers the virtual touchscreen and falls back to injected input. 'hid' requires the virtual touchscreen and fails if the device does not provide one — use it when the gesture must be real kernel input or must fail loudly."New value: +"Input path. 'auto' (default) prefers the virtual touchscreen and falls back to injected input. 'hid' requires the virtual touchscreen and fails if the device does not provide one — use it when the gesture must be real kernel input or must fail loudly."
  2. Changed1 schema field changed
    • changedInput schema / properties / input / description
      Previous value: -"Input path. 'auto' (default) prefers the virtual touchscreen and falls back to injected input. 'hid' requires the virtual touchscreen and fails if the device does not provide one — use it when the gesture must be real kernel input or must fail loudly."New value: +"Input path. 'auto' (default) prefers the virtual touchscreen and falls back to injected input. 'hid' requires the virtual touchscreen and fails if the device does not provide one — use it when the gesture must be real kernel input or must fail loudly."
  3. Changed1 schema field changed
    • addedInput schema / properties / input
      Added value: +{
+  "description": "Input path. 'auto' (default) prefers the virtual touchscreen and falls back to injected input. 'hid' requires the virtual touchscreen and fails if the device does not provide one — use it when the gesture must be real kernel input or must fail loudly.",
+  "enum": [
+    "auto",
+    "hid"
+  ],
+  "type": "string"
+}
  4. Added

TDQS

A4.7/5.0
Behavior5/5

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

No annotations provided, so the description carries full disclosure. It details scale direction and magnitude, the vertical-axis finger constraint, interaction with system bars, undetectable bottom sheets, the reply contents (finger endpoints and span), physical-pixel coordinates, and the hid vs auto input path with loud-failure behavior. Nothing is left hidden.

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?

The description is dense but every sentence earns its place. It front-loads the core action and scale rule, then systematically covers placement constraints, UI pitfalls, reply verification, coordinate system, and the strict input mode. No fluff or repetition.

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?

With no output schema, it discloses the reply fields (endpoints and span) and how to interpret them. It covers all six parameters through explanation or reference to schema. It addresses common failure modes (weak zoom near edges, notification shade, bottom sheets) and the hid vs auto distinction, making it complete for an agent to invoke 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?

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema: it explains scale semantics (zoom in/out, approximate doubling/halving), the role of x/y as the pinch centre, and the physical-pixel interpretation tied to device_page_source. It does not detail duration, but that is already self-explanatory in the schema.

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: 'Two-finger pinch-to-zoom centred at (x,y) on an Android device.' It distinguishes itself by naming the scale semantics and the old alias device_uhid_pinch, clearly differentiating from other gesture tools like device_gesture_path and device_swipe.

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?

Provides clear contextual guidance on where to place the centre (middle third), warns about status/nav bars and bottom sheets, and explains when to use input='hid'. It does not explicitly list alternative tools to compare against, but the placement advice and failure-mode discussion effectively steer correct usage.

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

All Robot Actions — Remote Device Control toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources