Skip to main content
Glama

Robot Actions — Remote Device Control

by com.robotactions.test
OverviewDiscussionsAdmin

ios_find_element

Find a UI element on an iOS device by its accessibility label or text. Returns the element center coordinates (x, y), bounds, and which strategy matched. On no match, returns similar visible labels to retry with. Prefer this (or ios_tap_by_label) over eyeballing coordinates from a screenshot. Requires an active iOS automation session (auto-starts if needed).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoElement type filter e.g. XCUIElementTypeButton, XCUIElementTypeCell (optional, used in class chain)
udidYesiOS device UDID
labelYesAccessibility label or visible text of the element to find
matchNoHow to match `label`. Default "contains" — strict, and the only modes that act without interpretation. "fuzzy" tolerates typos and word-order drift, and is tried ONLY after strict finds nothing; it REFUSES when two candidates are too close rather than guessing between them (e.g. "Sign" vs Sign In / Sign Out), and reports which attribute it matched.
strategyNoElement finding strategy to try first. Defaults to trying class chain → predicate string → accessibility id → name → xpath in order.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / match
      Added value: +{
+  "description": "How to match `label`. Default \"contains\" — strict, and the only modes that act without interpretation. \"fuzzy\" tolerates typos and word-order drift, and is tried ONLY after strict finds nothing; it REFUSES when two candidates are too close rather than guessing between them (e.g. \"Sign\" vs Sign In / Sign Out), and reports which attribute it matched.",
+  "enum": [
+    "exact",
+    "contains",
+    "fuzzy"
+  ],
+  "type": "string"
+}
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are supplied, so the description carries the behavioral burden. It discloses return contents (center coordinates, bounds, matched strategy), the no-match fallback of similar labels, and automatic session start. It does not mention timeouts or explicitly state that it is non-mutating, but the key behaviors are covered for a lookup tool.

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?

Three sentences, front-loaded with the action, followed by return values, no-match behavior, and usage guidance. Every sentence earns its place with no filler or redundant schema 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?

With no output schema, the description usefully names the return values and the no-match fallback, and it addresses session requirements. It omits explicit failure/timeout details and optional parameter guidance, but those are covered by the schema, making the overall definition largely complete.

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 coverage is 100%, so the baseline is 3. The description confirms that 'label' means accessibility label or visible text but adds little beyond the schema's own parameter documentation; the detailed match and strategy semantics live 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?

Opens with a specific verb, target platform, and matching mechanism: 'Find a UI element on an iOS device by its accessibility label or text.' It also states what the tool returns, so an agent can immediately recognize it as a locator rather than an action tool like ios_tap_by_label.

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?

Explicitly advises preferring this tool (or ios_tap_by_label) over eyeballing screenshot coordinates, which gives clear usage context. It does not fully spell out when to choose this over related siblings such as ios_elements_in_region or ios_tap_by_label, so it 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.

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