Robot Actions — Remote Device Control

ios_safari_list_pages

List inspectable Safari pages on an iOS device via the Web Inspector CDP bridge. Returns index, pageId (the CDP target id), url, title, type, active, and state per page, plus a top-level currentActiveTab (the pageId on screen, or null when none is). index is positional within THIS listing and is not stable across calls — resolve it to a pageId here, then pass that pageId. iOS shows exactly ONE tab at a time, so every ios_safari_* tool called WITHOUT pageId drives the active tab and refuses a backgrounded one — you do NOT need to list pages and thread an id just to act on the current tab, only to target a DIFFERENT one. state says what each page is doing, and the distinction matters because the fixes are opposite: "foreground" = the tab on screen (at most one, and it is the active: true one); "background" = alive but not visible, because another tab or another app is in front — pass its pageId explicitly to drive it anyway; "unresponsive" = the page answers nothing, either because it is suspended (device asleep or locked) or because a dialog (alert/confirm/prompt) is open and blocking the page — those look identical from here, so take a screenshot to tell them apart rather than assuming the device is asleep; "unprobed" = past the probe cap, nothing was measured. Pages "background" with no foreground means Safari is not frontmost. safariFrontmost answers that directly when the device can be asked: false means Safari is NOT the app on screen, so NO tab here is what the device is showing — the tabs are still alive and drivable, but do not read one as "what the user sees", and do not mistake a tab left over from earlier work for the one you just opened. It is omitted when it could not be determined, never guessed. Confirming state costs one bounded check per page (run in parallel), so this is a little slower than a bare listing and never fails the whole call just because nothing is in the foreground. Requires Web Inspector enabled: Settings → Safari → Advanced → Web Inspector.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`udid`	Yes	iOS device UDID
`platformVersion`	No	Ignored (kept for compatibility)

Schema Changelog

Changes observed during successful MCP inspections.

First observedAug 4, 2026

TDQS

A4.6/5.0

Behavior5/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 that confirming state costs a bounded check per page, that the call never fails solely due to no foreground page, that safariFrontmost is omitted when undetermined (never guessed), and the ambiguity of 'unresponsive' states. It also explains the instability of index and the requirement for Web Inspector, all beyond what annotations would typically provide.

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 long but dense with essential information, and the main purpose is front-loaded. It is structured logically with clear sections (return values, index caveat, state explanations, safariFrontmost, cost). While it could be trimmed slightly, the length is justified by the tool's complexity, so it earns a 4 rather than a 5.

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?

Given there is no output schema, the description comprehensively explains all return fields, the state machine, and how to interpret the results. It also covers prerequisites and the relationship to other tools, leaving nothing an agent needs to know to call it correctly.

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?

The input schema already fully describes both parameters (udid and platformVersion, with platformVersion marked as ignored). The description does not add additional parameter-level semantics beyond what the schema provides, so the baseline score of 3 applies.

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 clearly states the verb 'List' and the resource 'inspectable Safari pages on an iOS device', and specifies the exact return fields. It differentiates from other ios_safari_* tools by explaining that listing is only needed to target a non-active tab, which is a distinct purpose.

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?

It explicitly states when to use this tool ('only to target a DIFFERENT one') and when not to ('you do NOT need to list pages... just to act on the current tab'). It also provides detailed guidance on interpreting states and when to use screenshots to disambiguate unresponsive pages, which directly informs whether to call this tool.

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?