Robot Actions — Remote Device Control

ios_tap

Tap at (x,y) on an iOS device screen — the FALLBACK for when an element has no usable label. Prefer ios_tap_by_label (taps by accessibility label via the automation session, no coordinate math, works even on zero-area elements) whenever the target has a name in ios_page_source. Coordinates here are in physical screen points and must come from ios_page_source (the authoritative source), NOT eyeballed from a screenshot. (On an Apple TV, which has no touchscreen, this is unavailable — select an element with tvos_select or tvos_focus instead.) Requires an active iOS automation session.

Input Schema

TableJSON Schema

Name	Required	Description
`x`	Yes	X coordinate in screen points (from ios_page_source element center)
`y`	Yes	Y coordinate in screen points (from ios_page_source element center)
`norm`	No	If true, x/y (and path points) are 0..1 FRACTIONS of the screen — pass `pixelInScreenshot ÷ screenshotSize` directly (scale-free, matches the frontend, avoids point-guessing). Default false = iOS screen points.
`udid`	Yes	iOS device UDID
`input`	No	Input path. 'auto' (default) drives the gesture through the automation session. 'hid' drives it through the direct input path instead, which needs no automation session — it reports 'no HID available' on iOS 17.x or with no tunnel.
`duration`	No	Tap hold duration in ms (default: 100)

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 17, 2026

addedInput schema / properties / input

Added value: +{
+  "description": "Input path. 'auto' (default) drives the gesture through the automation session. 'hid' drives it through the direct input path instead, which needs no automation session — it reports 'no HID available' on iOS 17.x or with no tunnel.",
+  "enum": [
+    "auto",
+    "hid"
+  ],
+  "type": "string"
+}

addedInput schema / properties / norm

Added value: +{
+  "description": "If true, x/y (and path points) are 0..1 FRACTIONS of the screen — pass `pixelInScreenshot ÷ screenshotSize` directly (scale-free, matches the frontend, avoids point-guessing). Default false = iOS screen points.",
+  "type": "boolean"
+}

First observedAug 4, 2026

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses the session requirement, coordinate source, and platform unavailability (Apple TV), which go beyond the schema. However, it does not mention potential side effects or behavior on failure, which would be useful for a tapping action.

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 a bit long but every sentence contributes: action, fallback status, alternative, coordinate guidance, TV exception, session requirement. It is front-loaded with the core action and the key decision point (fallback vs label). No fluff or repetition.

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?

Given 6 parameters, no output schema, and no annotations, this description covers the critical operational constraints: when to use, where to get coordinates, session requirement, and platform exclusion. It does not describe the return value, but that is less critical for a tap action and no output schema exists.

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 explicit warning that coordinates must come from ios_page_source, not eyeballed from a screenshot, which enhances x/y semantics beyond the schema. It does not discuss the norm, input, or duration params, but the schema already covers those well.

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 action (tap at coordinates) and resource (iOS device screen), and immediately frames itself as the FALLBACK alternative to ios_tap_by_label. It also clarifies coordinate sourcing, making its purpose distinct from sibling tools without ambiguity.

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

Usage Guidelines5/5

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

Explicitly says 'Prefer ios_tap_by_label ... whenever the target has a name in ios_page_source', and names tvos_select/tvos_focus as alternatives on Apple TV. This gives clear when-to-use and when-not-to-use guidance, with precise alternative tool names.

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 tools Inspect

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

Need Help?