Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
IOS_AGENT_MODELNoThe model name to use with the configured provider.
IOS_AGENT_PROVIDERNoThe model provider to use (e.g., 'openai', 'anthropic', 'gemini'). If not set, a default provider is used.
IOS_MCP_ALLOW_DEVICENoSet to '1' to allow controlling a physical iPhone. Controlling physical hardware is opt-in; the default is '0' (not allowed).0

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}
logging
{}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
extensions
{
  "io.modelcontextprotocol/ui": {}
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
ios_doctorA

Check that this machine can drive an iOS device, and say how to fix what it can't.

Run this first when a session fails to start, when a device does not appear, or after an Xcode or iOS upgrade. Every failing check comes with a concrete remedy.

ios_list_devicesA

List iOS Simulators and attached physical iPhones available for automation.

ready is false when something blocks automation; blockers says what.

ios_open_sessionA

Attach to a device and start driving it.

Boots the simulator or verifies the phone, starts WebDriverAgent, and opens a tuned session. Omitting device prefers an already-booted simulator over a connected iPhone, so acting on a real device is always a deliberate choice.

ios_session_statusA

Report the current session: device, foreground app, and safety state.

ios_close_sessionA

Release the device and shut down its WebDriverAgent runner.

ios_list_appsA

List apps installed on the device, with their bundle identifiers.

ios_launch_appB

Bring an app to the foreground and return its screen.

ios_terminate_appC

Force-quit an app.

ios_open_urlA

Open a URL or deep link.

Usually the cheapest way to reach a screen: a deep link skips the navigation an agent would otherwise have to tap through.

ios_install_appA

Install an app from a local .app or .ipa.

ios_observeA

Read the screen as a compact list of elements with short refs.

Each line is one element: e7 button "Send" @(340,70). Pass those refs to the action tools rather than coordinates.

If the result says elements were omitted, narrow with query or region instead of raising budget; a smaller answer is usually the more useful one.

ios_screenshotA

Capture the screen as an image.

Use this when an element has no accessibility label, when the layout matters, or when ios_observe cannot find something you can plainly see. With annotate_refs the boxes are labelled with the refs from the last observation, so you can pick one by eye.

ios_read_textA

Read the text of the screen, or of one element and everything inside it.

Use this to extract content, rather than ios_observe, which is shaped for deciding what to tap.

ios_findA

Search the screen's accessibility tree, including what the digest hides.

Prefer ios_observe with a query when you want a usable digest you can tap from: what it returns carries refs. Use this when ios_observe shows nothing matching but the text is on the device, or when a tap keeps missing. It reads the tree before compaction, so it reports matches the digest dropped, which ios_observe by construction cannot, and each one says whether it is shown or hidden. A hidden match is the diagnosis: the words are on screen and perception is why you cannot reach them. Name it by the id reported here.

ios_wait_forA

Wait for something to appear or disappear.

Prefer this over guessing a sleep. It returns as soon as the condition holds, and reports failure rather than raising, so a timeout is something you can reason about.

ios_get_logsA

Read recent device logs. Useful when an app misbehaves and the UI does not say why.

ios_export_traceA

Return the ordered record of everything this session has done.

Useful for explaining what happened, and for turning a successful run into a regression test.

ios_tapA

Tap an element and return the resulting screen.

Prefer ref over target; it is exact and cannot be misread. Taps on things like Send, Pay, or Delete need approval first.

ios_typeA

Type into a field, focusing it first when a ref or target is given.

ios_type_secretA

Type a stored secret without ever seeing its value.

The value is read from the host keychain and sent straight to the device. Use this for every password and one-time code; never put a real credential into ios_type, where it would enter the transcript.

ios_set_valueA

Set a switch, slider, or picker wheel to a value.

'on' or 'off' for a switch, a percentage such as '40%' or a fraction for a slider, and the option spelled the way the wheel spells it for a picker. A wheel is turned a row at a time and read back after each one, so an option it does not contain fails listing what it does.

Prefer this over tapping a switch: it checks the current state first, so asking for 'on' when it is already on does nothing rather than turning it off.

Steppers and segmented controls are not set this way. iOS reports their parts and the digest shows them, so tap 'Increment', 'Decrement', or the segment by its own label.

ios_scrollA

Scroll, optionally until some text comes into view.

With until, this stops as soon as the text appears and gives up when the content stops moving, so it will not spin at the end of a list.

ios_swipeA

Swipe once, for carousels, page views, and swipe-to-reveal rows.

ios_dragA

Drag one element onto another, for reordering lists and moving items.

ios_press_buttonA

Press a hardware button or a keyboard key.

ios_handle_alertA

Answer a system alert.

Read the alert text before choosing. Accepting blindly is how an agent grants a permission or confirms a deletion nobody wanted.

ios_haltB

Stop this session from taking further action.

ios_resumeA

Clear a halt after a human has decided it is safe to continue.

ios_set_permissionA

Set a privacy permission without going through the alert.

Simulator only. On a real phone there is no API for this: drive the Settings app, or answer the permission alert with ios_handle_alert.

ios_clipboardA

Read or write the device clipboard.

Writing is often faster and more reliable than typing a long string, which the on-screen keyboard can mangle with autocorrect.

ios_set_device_stateA

Change device-level state. Appearance, location, and status bar are Simulator only.

Prompts

Interactive templates invoked by user choice

NameDescription
ios_operatorHow to drive an iOS device well: the observe, act, verify loop and its rules.

Resources

Contextual data attached and managed by the client

NameDescription
screenshot_resourceThe current screen, as a resource for clients that prefer to pull it.
devices_resourceEvery simulator and attached iPhone, with readiness.
session_resourceThe current session, or a note that none is open.
screen_resourceThe last observed screen, without spending a tool call.
capabilities_resourceWhich tools work on the attached device. Several capabilities are Simulator-only, and an agent that knows this up front does not waste a turn discovering it.

TDQS

A3.7/5.0

Scored across 31 tools

Disambiguation5/5

Each tool has a clearly distinct purpose. Screen-reading tools are differentiated by whether you need refs (observe), hidden elements (find), pixel layout (screenshot), or raw text (read_text). Interaction tools are gesture-specific with no meaningful overlap.

Naming Consistency4/5

The ios_ prefix is consistent, but the action part varies: most are verb_noun (tap, scroll, launch_app), but there are verb phrases (wait_for, set_device_state), bare verbs (halt, resume), and a noun (doctor). This is mostly predictable but not uniform.

Tool Count3/5

31 tools is heavy, but the domain of iOS automation is broad, requiring separate tools for device management, session control, UI observation, gestures, and app operations. Still, the count is above the typical well-scoped range, making it borderline.

Completeness4/5

The surface covers the main automation lifecycle: session, devices, apps, UI inspection, interaction, alerts, permissions, and diagnostics. Minor gaps like app uninstall or springboard manipulation are absent, but agents can work around them.

Maintenance

ActivityMaintained
ResponsivenessNo issues