The iOS Simulator MCP server allows interaction with iOS simulators to perform UI automation tasks, including:
Get the ID of the currently booted iOS simulator
Describe accessibility elements on the screen
Tap on specific screen coordinates
Input text into the simulator
Swipe between coordinates
Get information about UI elements at specific locations
Take screenshots or record videos of the simulator screen
Integrates with Facebook's IDB tool to communicate with and control iOS simulators, enabling the MCP server to perform UI automation tasks.
Provides tools for interacting with iOS simulators, including getting simulator information, controlling UI interactions (tapping, swiping, text input), and inspecting UI elements for accessibility testing and automation.
Enables operation on macOS systems where iOS simulators run, providing simulator access and control capabilities specific to the macOS environment.
Utilizes Xcode's iOS simulator infrastructure to enable UI automation, testing, and interaction with simulated iOS devices.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@iOS Simulator MCP tap the login button at coordinates 200, 400"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for interacting with iOS simulators. This server allows you to interact with iOS simulators by getting information about them, controlling UI interactions, and inspecting UI elements.
Security Notice: Command injection vulnerabilities present in versions < 1.3.3 have been fixed. Please update to v1.3.3 or later. See SECURITY.md for details.
https://github.com/user-attachments/assets/a88e449c-8f1d-46a5-9816-0f97e071c460
This project has been featured and mentioned in various publications and resources:
Claude Code Best Practices article - Anthropic's engineering blog showcasing best practices
React Native Newsletter Issue 187 - Featured in the most popular React Native community newsletter
Mobile Automation Newsletter - #56 - Featured a long running newsletter about mobile testing and automation resources
punkeye/awesome-mcp-server listing - Listed in one of the most popular curated awesome MCP servers collection
Related MCP server: iOS Device Control MCP Server
get_booted_sim_idDescription: Get the ID of the currently booted iOS simulator
Parameters: No Parameters
open_simulatorDescription: Opens the iOS Simulator application
Parameters: No Parameters
ui_describe_allDescription: Describes accessibility information for the entire screen in the iOS Simulator
Parameters:
{
/**
* Udid of target, can also be set with the IDB_UDID env var
* Format: UUID (8-4-4-4-12 hexadecimal characters)
*/
udid?: string;
}ui_tapDescription: Tap on the screen in the iOS Simulator
Parameters:
{
/**
* Press duration in seconds (decimal numbers allowed)
*/
duration?: string;
/**
* Udid of target, can also be set with the IDB_UDID env var
* Format: UUID (8-4-4-4-12 hexadecimal characters)
*/
udid?: string;
/** The x-coordinate */
x: number;
/** The y-coordinate */
y: number;
}ui_typeDescription: Input text into the iOS Simulator
Parameters:
{
/**
* Udid of target, can also be set with the IDB_UDID env var
* Format: UUID (8-4-4-4-12 hexadecimal characters)
*/
udid?: string;
/**
* Text to input
* Format: ASCII printable characters only
*/
text: string;
}ui_swipeDescription: Swipe on the screen in the iOS Simulator
Parameters:
{
/**
* Swipe duration in seconds (decimal numbers allowed)
*/
duration?: string;
/**
* Udid of target, can also be set with the IDB_UDID env var
* Format: UUID (8-4-4-4-12 hexadecimal characters)
*/
udid?: string;
/** The starting x-coordinate */
x_start: number;
/** The starting y-coordinate */
y_start: number;
/** The ending x-coordinate */
x_end: number;
/** The ending y-coordinate */
y_end: number;
/** The size of each step in the swipe (default is 1) */
delta?: number;
}ui_describe_pointDescription: Returns the accessibility element at given co-ordinates on the iOS Simulator's screen
Parameters:
{
/**
* Udid of target, can also be set with the IDB_UDID env var
* Format: UUID (8-4-4-4-12 hexadecimal characters)
*/
udid?: string;
/** The x-coordinate */
x: number;
/** The y-coordinate */
y: number;
}ui_find_elementDescription: Searches the accessibility tree and returns elements matching the given criteria
Parameters:
{
/** Array of search strings. An element matches if ANY string matches against its AXLabel or AXUniqueId */
search: string[];
/** Filter by element type (e.g. 'Button', 'StaticText', 'Group'). Case-insensitive exact match */
type?: string;
/** Match mode: 'substring' (default) or 'exact' */
matchMode?: "substring" | "exact";
/** Whether search matching is case-sensitive (default: false) */
caseSensitive?: boolean;
/**
* Udid of target, can also be set with the IDB_UDID env var
* Format: UUID (8-4-4-4-12 hexadecimal characters)
*/
udid?: string;
}ui_viewDescription: Get the image content of a compressed screenshot of the current simulator view
Parameters:
{
/**
* Udid of target, can also be set with the IDB_UDID env var
* Format: UUID (8-4-4-4-12 hexadecimal characters)
*/
udid?: string;
}screenshotDescription: Takes a screenshot of the iOS Simulator
Parameters:
{
/**
* Udid of target, can also be set with the IDB_UDID env var
* Format: UUID (8-4-4-4-12 hexadecimal characters)
*/
udid?: string;
/** File path where the screenshot will be saved. If relative, it uses the directory specified by the `IOS_SIMULATOR_MCP_DEFAULT_OUTPUT_DIR` env var, or `~/Downloads` if not set. */
output_path: string;
/** Image format (png, tiff, bmp, gif, or jpeg). Default is png. */
type?: "png" | "tiff" | "bmp" | "gif" | "jpeg";
/** Display to capture (internal or external). Default depends on device type. */
display?: "internal" | "external";
/** For non-rectangular displays, handle the mask by policy (ignored, alpha, or black) */
mask?: "ignored" | "alpha" | "black";
}record_videoDescription: Records a video of the iOS Simulator using simctl directly
Parameters:
{
/**
* Udid of target, can also be set with the IDB_UDID env var
* Format: UUID (8-4-4-4-12 hexadecimal characters)
*/
udid?: string;
/** Optional output path. If not provided, a default name will be used. The file will be saved in the directory specified by `IOS_SIMULATOR_MCP_DEFAULT_OUTPUT_DIR` or in `~/Downloads` if the environment variable is not set. */
output_path?: string;
/** Specifies the codec type: "h264" or "hevc". Default is "hevc". */
codec?: "h264" | "hevc";
/** Display to capture: "internal" or "external". Default depends on device type. */
display?: "internal" | "external";
/** For non-rectangular displays, handle the mask by policy: "ignored", "alpha", or "black". */
mask?: "ignored" | "alpha" | "black";
/** Force the output file to be written to, even if the file already exists. */
force?: boolean;
}stop_recordingDescription: Stops the simulator video recording using killall
Parameters: No Parameters
install_appDescription: Installs an app bundle (.app or .ipa) on the iOS Simulator
Parameters:
{
/**
* Udid of target, can also be set with the IDB_UDID env var
* Format: UUID (8-4-4-4-12 hexadecimal characters)
*/
udid?: string;
/** Path to the app bundle (.app directory or .ipa file) to install */
app_path: string;
}launch_appDescription: Launches an app on the iOS Simulator by bundle identifier
Parameters:
{
/**
* Udid of target, can also be set with the IDB_UDID env var
* Format: UUID (8-4-4-4-12 hexadecimal characters)
*/
udid?: string;
/** Bundle identifier of the app to launch (e.g., com.apple.mobilesafari) */
bundle_id: string;
/** Terminate the app if it is already running before launching */
terminate_running?: boolean;
/** Optional environment variables passed via SIMCTL_CHILD_ to simctl launch */
env?: Record<string, string>;
}Notes: Environment variables are passed using SIMCTL_CHILD_ because simctl launch does not support --env/--envs on all Xcode versions.
Example:
{
"bundle_id": "com.example.app",
"terminate_running": true,
"env": {
"FOO": "bar",
"BAZ": "qux"
}
}terminate_appDescription: Terminates a running app on the iOS Simulator by bundle identifier. Useful for testing cold-start flows and verifying crash recovery without reinstalling the app.
Parameters:
{
/**
* Udid of target, can also be set with the IDB_UDID env var
* Format: UUID (8-4-4-4-12 hexadecimal characters)
*/
udid?: string;
/** Bundle identifier of the app to terminate (e.g., com.apple.mobilesafari) */
bundle_id: string;
}open_urlDescription: Opens a URL or deep link in the iOS Simulator. Handles https:// URLs (via Safari), custom URL schemes, and universal links — essential for testing deep-link routing and OAuth redirect flows.
Parameters:
{
/**
* Udid of target, can also be set with the IDB_UDID env var
* Format: UUID (8-4-4-4-12 hexadecimal characters)
*/
udid?: string;
/** The URL or deep link to open (e.g., https://example.com or myapp://screen/detail) */
url: string;
}list_appsDescription: Lists all installed apps on the iOS Simulator with their bundle identifiers and display names, sorted alphabetically. Removes the need to look up bundle IDs manually before calling launch_app or terminate_app.
Parameters:
{
/**
* Udid of target, can also be set with the IDB_UDID env var
* Format: UUID (8-4-4-4-12 hexadecimal characters)
*/
udid?: string;
}This MCP server allows AI assistants integrated with a Model Context Protocol (MCP) client to perform Quality Assurance tasks by making tool calls. This is useful immediately after implementing features to help ensure UI consistency and correct behavior.
After a feature implementation, instruct your AI assistant within its MCP client environment to use the available tools. For example, in Cursor's agent mode, you could use the prompts below to quickly validate and document UI interactions.
Verify UI Elements:
Verify all accessibility elements on the current screenConfirm Text Input:
Enter "QA Test" into the text input field and confirm the input is correctCheck Tap Response:
Tap on coordinates x=250, y=400 and verify the expected element is triggeredValidate Swipe Action:
Swipe from x=150, y=600 to x=150, y=100 and confirm correct behaviorDetailed Element Check:
Describe the UI element at position x=300, y=350 to ensure proper labeling and functionalityShow Your AI Agent the Simulator Screen:
View the current simulator screenTake Screenshot:
Take a screenshot of the current simulator screen and save it to my_screenshot.pngRecord Video:
Start recording a video of the simulator screen (saves to the default output directory, which is `~/Downloads` unless overridden by `IOS_SIMULATOR_MCP_DEFAULT_OUTPUT_DIR`)Stop Recording:
Stop the current simulator screen recordingInstall App:
Install the app at path/to/MyApp.app on the simulatorLaunch App:
Launch the Safari app (com.apple.mobilesafari) on the simulatorAgents can waste a lot of iterations tapping and swiping their way to a deeply nested route. When your app registers a URL scheme (or Universal Link), it's usually faster to jump directly to the target screen instead of navigating there step by step.
You can open a deep link with uri-scheme:
npx uri-scheme open "myapp://products/42" --iosThis targets the currently booted simulator. Under the hood it's equivalent to:
xcrun simctl openurl booted "myapp://products/42"Both work for custom schemes (myapp://...) and web URLs (https://..., which
trigger Universal Links if your app is configured for them).
Example prompt:
Open the deep link myapp://products/42 in the simulator, then verify the product
details screen is shownUse this to shorten agent loops: deep link to the screen under test, then use the
UI tools (ui_describe_all, ui_tap, ui_view, …) to validate it.
Node.js 20 or later
macOS (as iOS simulators are only available on macOS)
Xcode and iOS simulators installed
Facebook IDB tool (see install guide)
This section provides instructions for integrating the iOS Simulator MCP server with different Model Context Protocol (MCP) clients.
Cursor manages MCP servers through its configuration file located at ~/.cursor/mcp.json.
Edit your Cursor MCP configuration file. You can often open it directly from Cursor or use a command like:
# Open with your default editor (or use 'code', 'vim', etc.)
open ~/.cursor/mcp.json
# Or use Cursor's command if available
# cursor ~/.cursor/mcp.jsonAdd or update the mcpServers section with the iOS simulator server configuration:
{
"mcpServers": {
// ... other servers might be listed here ...
"ios-simulator": {
"command": "npx",
"args": ["-y", "ios-simulator-mcp"]
}
}
}Ensure the JSON structure is valid, especially if mcpServers already exists.
If you prefer pnpm, use its dlx runner instead:
{
"mcpServers": {
"ios-simulator": {
"command": "pnpm",
"args": ["dlx", "ios-simulator-mcp"]
}
}
}Restart Cursor for the changes to take effect.
Clone this repository:
git clone https://github.com/joshuayoes/ios-simulator-mcp
cd ios-simulator-mcpInstall dependencies (npm is the default; pnpm is also supported):
npm install
# or, using pnpm (installs from the committed pnpm-lock.yaml):
pnpm installBuild the project:
npm run build
# or:
pnpm run buildEdit your Cursor MCP configuration file (as shown in Option 1).
Add or update the mcpServers section, pointing to your local build:
{
"mcpServers": {
// ... other servers might be listed here ...
"ios-simulator": {
"command": "node",
"args": ["/full/path/to/your/ios-simulator-mcp/build/index.js"]
}
}
}Important: Replace /full/path/to/your/ with the absolute path to where you cloned the ios-simulator-mcp repository.
Restart Cursor for the changes to take effect.
Claude Code CLI can manage MCP servers using the claude mcp commands or by editing its configuration files directly. For more details on Claude Code MCP configuration, refer to the official documentation.
Add the server using the claude mcp add command:
claude mcp add ios-simulator npx ios-simulator-mcp
# or, with pnpm:
claude mcp add ios-simulator -- pnpm dlx ios-simulator-mcpRestart any running Claude Code sessions if necessary.
Clone this repository, install dependencies, and build the project as described in the Cursor "Local Development" steps 1-3.
Add the server using the claude mcp add command, pointing to your local build:
claude mcp add ios-simulator -- node "/full/path/to/your/ios-simulator-mcp/build/index.js"Important: Replace /full/path/to/your/ with the absolute path to where you cloned the ios-simulator-mcp repository.
Restart any running Claude Code sessions if necessary.
Variable | Description | Example |
| A comma-separated list of tool names to filter out from being registered. |
|
| Specifies a default directory for output files like screenshots and video recordings. If not set, |
|
| Specifies a custom path to the IDB executable. If not set, |
|
{
"mcpServers": {
"ios-simulator": {
"command": "npx",
"args": ["-y", "ios-simulator-mcp"],
"env": {
"IOS_SIMULATOR_MCP_FILTERED_TOOLS": "screenshot,record_video,stop_recording",
"IOS_SIMULATOR_MCP_DEFAULT_OUTPUT_DIR": "~/Code/awesome-project/tmp",
"IOS_SIMULATOR_MCP_IDB_PATH": "~/bin/idb"
}
}
}
}MIT
Get the ID of the currently booted iOS simulator
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint: true and openWorldHint: true. The description adds no behavioral context beyond stating the purpose. It does not mention what happens if no simulator is booted or any error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It front-loads the key information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (no parameters, no output schema, no nested objects), the description is complete enough for the tool's purpose. It tells the agent what the tool does without requiring additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (schema coverage 100% trivially). The description does not need to explain parameters, and the baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the specific resource 'ID of the currently booted iOS simulator'. It distinguishes itself from sibling tools like install_app, launch_app, and UI tools which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the simulator ID is needed, but does not provide explicit guidance on when to use or not use this tool, nor does it mention alternatives. With no parameters and a clear purpose, the implied usage is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Installs an app bundle (.app or .ipa) on the iOS Simulator
| Name | Required | Description | Default |
|---|---|---|---|
| udid | No | Udid of target, can also be set with the IDB_UDID env var | |
| app_path | Yes | Path to the app bundle (.app directory or .ipa file) to install |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond the annotations. readOnlyHint=false already signals a write operation, but the description does not disclose prerequisites (e.g., whether the simulator must be booted), side effects (e.g., overwriting an existing installation), or return behavior. No annotation contradiction is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no unnecessary words or repetition. It efficiently conveys the tool's purpose without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with good schema coverage and annotations, the description is largely sufficient. It clearly states the action and target. The lack of information about side effects or prerequisites is a minor gap, but the annotations and schema cover the essential details for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters (udid and app_path) are fully documented. The description does not add any parameter-specific meaning beyond what the schema already provides, thus earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb 'installs' and the resource ('app bundle (.app or .ipa) on the iOS Simulator'). It is distinct from sibling tools like launch_app or list_apps, as installation is a different operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the verb 'installs' — an agent would know to use this when needing to install an app on the simulator. However, there is no explicit guidance on alternatives or when not to use it (e.g., for launching or listing apps).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launches an app on the iOS Simulator by bundle identifier
| Name | Required | Description | Default |
|---|---|---|---|
| env | No | Environment variables to pass to simctl launch | |
| udid | No | Udid of target, can also be set with the IDB_UDID env var | |
| bundle_id | Yes | Bundle identifier of the app to launch (e.g., com.apple.mobilesafari) | |
| terminate_running | No | Terminate the app if it is already running before launching |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and openWorldHint=true, signaling a mutating, side-effectful operation. The description adds no further behavioral context—no side effects, failure modes, prerequisites, or return value. 'Launches an app' largely restates the tool name and the annotation's implication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 11-word sentence is information-dense and free of fluff. It is perfectly front-loaded with the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema thoroughly documents all parameters and the annotations cover the safety profile, but the description omits expected output (e.g., simctl launch returns a PID), error cases (app not installed, simulator not booted), and any guidance on the env or terminate_running parameters. Adequate for a simple launch action but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with all four parameters described, so the baseline of 3 applies. The description's 'by bundle identifier' merely reinforces the required bundle_id parameter without adding semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Launches'), a clear resource ('an app on the iOS Simulator'), and an explicit method ('by bundle identifier'). This clearly distinguishes it from sibling tools like install_app, terminate_app, and open_url.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it launches an app on the iOS Simulator, so an agent knows when to reach for it. However, it does not explicitly mention alternatives or exclusions, such as needing to install the app first or ensuring the simulator is booted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all installed apps on the iOS Simulator with their bundle identifiers and display names
| Name | Required | Description | Default |
|---|---|---|---|
| udid | No | Udid of target, can also be set with the IDB_UDID env var |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, which convey the read-only and safe nature of this operation. The description adds context about the scope ('installed apps on the iOS Simulator') and return fields, but does not describe additional behavioral details beyond what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the action and resource, containing no extraneous information or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with one optional parameter and no output schema, the description is adequately complete. It states what is listed and what details are included. Minor gaps like requiring a booted simulator are implied by the 'iOS Simulator' context but not explicitly stated, which is acceptable for such a lightweight tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single optional 'udid' parameter with a clear description. The tool description does not mention the parameter, but the schema fully explains its meaning (target UDID with env var fallback), so no additional semantic value is added by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lists' and specifies the resource: 'all installed apps on the iOS Simulator'. It also mentions the output fields ('bundle identifiers and display names'), which distinguishes it from sibling tools like install_app or launch_app that perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for seeing installed apps, but does not explicitly state when to use it versus alternatives, nor does it mention any exclusion criteria. There is no direct sibling that also lists apps, so the usage context is somewhat implied but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Opens the iOS Simulator application
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and openWorldHint=true, so the description's statement 'Opens' is consistent but adds no new behavioral insight. With annotations covering the safety profile, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words, perfectly suited for a simple action tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description completely informs the agent about its purpose and effect, making it sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description adds no parameter information but doesn't need to; baseline score of 4 is given due to zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Opens') and the specific resource ('iOS Simulator application'), distinguishing it from sibling tools like launch_app (which launches a specific app) and other simulator operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when the simulator is already open or how it relates to other tools like install_app. This lack of context may lead to incorrect selection in a multi-tool scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Opens a URL in the iOS Simulator, useful for testing deep links and universal links
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL or deep link to open (e.g., https://example.com or myapp://screen/detail) | |
| udid | No | Udid of target, can also be set with the IDB_UDID env var |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, so the mutation aspect is known. The description only says 'opens a URL', which adds minimal behavioral context. It does not disclose potential side effects like launching an app or requiring a booted simulator, but with annotations covering the safety profile, the added value is limited yet not absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and communicates the key use case. It contains no fluff or redundant information, making it exceptionally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two params and no output schema, the description is largely sufficient. It explains the purpose and use case, and the schema covers parameters. It lacks explicit mention of preconditions like a booted simulator, but given the surrounding tools (e.g., get_booted_sim_id) and simplicity, the omission is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'url' and 'udid' already documented in the schema. The tool description does not add any additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Opens' and resource 'URL in the iOS Simulator', clearly differentiating from sibling tools like launch_app (which launches an app) and open_simulator (which opens the simulator app). It also states the intended use case (testing deep links and universal links), fully clarifying the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by mentioning it is useful for testing deep links and universal links, implying when to use it. However, it does not explicitly name alternatives or state when not to use it, stopping short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Records a video of the iOS Simulator using simctl directly
| Name | Required | Description | Default |
|---|---|---|---|
| mask | No | For non-rectangular displays, handle the mask by policy: "ignored", "alpha", or "black". | |
| udid | No | Udid of target, can also be set with the IDB_UDID env var | |
| codec | No | Specifies the codec type: "h264" or "hevc". Default is "hevc". | |
| force | No | Force the output file to be written to, even if the file already exists. | |
| display | No | Display to capture: "internal" or "external". Default depends on device type. | |
| output_path | No | Optional output path. If not provided, a default name will be used. The file will be saved in the directory specified by `IOS_SIMULATOR_MCP_DEFAULT_OUTPUT_DIR` or in `~/Downloads` if the environment variable is not set. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal a non-read-only, open-world operation, but the description adds no behavioral context beyond the literal action. It does not disclose that recording is an ongoing process requiring a separate stop call, nor does it mention output-file behavior or other side effects. There is no annotation contradiction, but the description fails to add meaningful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant detail. It states the action, resource, and implementation method efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the rich schema, the description omits critical operational context such as how long recording lasts, how to stop it, and what the tool returns. The existence of a stop_recording sibling makes this gap especially significant, as the agent cannot infer the full workflow from the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage with detailed explanations for all six parameters, including udid, codec, display, and output_path. The description itself adds no parameter-level semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Records' and identifies the resource as 'a video of the iOS Simulator'. It clearly distinguishes the tool from sibling tools like screenshot (still image) and stop_recording (ending a recording).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a video of the simulator is needed, but it provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives or prerequisites such as a booted simulator or how this relates to screenshot or stop_recording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Takes a screenshot of the iOS Simulator
| Name | Required | Description | Default |
|---|---|---|---|
| mask | No | For non-rectangular displays, handle the mask by policy (ignored, alpha, or black) | |
| type | No | Image format (png, tiff, bmp, gif, or jpeg). Default is png. | |
| udid | No | Udid of target, can also be set with the IDB_UDID env var | |
| display | No | Display to capture (internal or external). Default depends on device type. | |
| output_path | Yes | File path where the screenshot will be saved. If relative, it uses the directory specified by the `IOS_SIMULATOR_MCP_DEFAULT_OUTPUT_DIR` env var, or `~/Downloads` if not set. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false and openWorldHint=true, and the description adds no further behavioral detail such as simulator boot requirement, file output location, or failure modes. It only restates the core action without enriching the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action, no filler words. Perfectly concise for the simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema and annotations cover most operational details, and the description states the core function. Missing usage alternatives and return behavior, but adequate for a simple screenshot tool with well-documented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description itself contributes no parameter information, but the schema already documents all five parameters with defaults and env var fallback.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'takes' and resource 'screenshot of the iOS Simulator', clearly stating the tool's function. This distinguishes it from sibling tools like record_video and ui_view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives; no exclusions or context provided. The description only states what it does, leaving the agent to infer usage from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stops the simulator video recording using killall
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate this is not read-only (readOnlyHint=false) and has open world effects (openWorldHint=true). The description adds the implementation method 'killall', which hints at forceful termination, but it doesn't disclose what happens if no recording is active, whether the recording file is saved, or any side effects. With annotations present, the description adds minimal extra behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that states the action and method. Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is largely complete. It could mention behavior when no recording is in progress (e.g., no-op or error), but for a basic stop action, the current text suffices. A 5 would require that extra edge-case context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100% (trivially). The description correctly doesn't attempt to explain parameters. With 0 params, the baseline is 4, and there is no gap to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Stops') and a clear resource ('the simulator video recording'), which directly distinguishes it from the sibling tool 'record_video' that starts recording. It also includes the implementation detail 'using killall', making the action unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description doesn't explicitly mention when to use this tool or list alternatives, the context is clear: it complements 'record_video' and is specific to simulator video recording. The absence of an explicit exclusion (e.g., 'only when recording is active') prevents a 5, but the purpose is self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Terminates a running app on the iOS Simulator by bundle identifier
| Name | Required | Description | Default |
|---|---|---|---|
| udid | No | Udid of target, can also be set with the IDB_UDID env var | |
| bundle_id | Yes | Bundle identifier of the app to terminate (e.g., com.apple.mobilesafari) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a mutating operation (readOnlyHint=false). The description adds that the action targets a running app on the iOS Simulator, which is useful, but it does not disclose failure modes, side effects, or requirements like needing a booted simulator. It provides some value beyond annotations but lacks richer behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, grammatically clean sentence that promptly states the action, target, and method. No filler or repetition, earning it the highest score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, this description sufficiently covers the core action. It lacks mention of error handling, simulator state prerequisites, or inverse relationship with launch_app, but these are not essential for basic invocation. Minor gaps keep it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents both parameters with descriptions (100% coverage), so the description's mention of 'by bundle identifier' adds no new semantic detail. The baseline of 3 applies since the schema does the heavy lifting for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Terminates' with a clear resource 'a running app on the iOS Simulator' and method 'by bundle identifier'. This precisely defines the tool's function and distinguishes it from sibling tools like launch_app and install_app.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for stopping a running app, which gives strong contextual use guidance. However, it does not explicitly mention alternatives or conditions when to avoid use, such as non-running apps or dependency on a booted simulator, missing the top benchmark.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describes accessibility information for the entire screen in the iOS Simulator
| Name | Required | Description | Default |
|---|---|---|---|
| udid | No | Udid of target, can also be set with the IDB_UDID env var |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds minimal extra context by specifying 'entire screen' versus a point, but does not elaborate on output format or behavior beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the action and scope. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description adequately conveys the tool's purpose. While it lacks explicit return-format details, the phrase 'accessibility information for the entire screen' gives sufficient context for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, documenting the udid parameter with pattern and env var note. The description adds no parameter-specific information, so it does not exceed the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Describes accessibility information for the entire screen in the iOS Simulator.' It uses a specific verb ('describes') and identifies the resource (accessibility information for the entire screen), which distinguishes it from sibling tools like ui_describe_point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as ui_describe_point or ui_find_element. The description only states what it does without any contextual usage hints or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the accessibility element at given co-ordinates on the iOS Simulator's screen
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | The x-coordinate | |
| y | Yes | The y-coordinate | |
| udid | No | Udid of target, can also be set with the IDB_UDID env var |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, providing safety context. The description adds that the tool returns an accessibility element, but it does not mention behavior for empty coordinates or coordinate system details. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that fully conveys the tool's function without unnecessary words. It is front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple point-query tool with good annotations, the description is adequate but misses details like coordinate system (points vs pixels), behavior when no element exists, and return format. Since there is no output schema, additional context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes all three parameters with 100% coverage, including x, y, and udid. The description adds no additional meaning beyond what the schema already provides, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Returns' and clearly states the resource: the accessibility element at given coordinates on the iOS Simulator's screen. It distinguishes itself from sibling tools like ui_describe_all by specifying that it targets a single point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to inspect a specific point on screen, but it does not explicitly state when to prefer this over alternatives like ui_describe_all or ui_find_element. No exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches the accessibility tree and returns elements matching the given criteria
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter by element type (e.g. 'Button', 'StaticText', 'Group'). Case-insensitive exact match | |
| udid | No | Udid of target, can also be set with the IDB_UDID env var | |
| search | Yes | Array of search strings. An element matches if ANY string matches against its AXLabel or AXUniqueId | |
| matchMode | No | Match mode for search strings: 'substring' (default) or 'exact' | substring |
| caseSensitive | No | Whether search matching is case-sensitive (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds context that it inspects the accessibility tree, but does not disclose return format, behavior when no elements match, or any nuances. This is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that wastes no words. It communicates the core action and expected result efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and multiple sibling tools, the description is minimal. It covers the basic purpose but lacks usage guidance, return details, or edge-case behavior, so it is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter (search, type, udid, matchMode, caseSensitive) has a description in the schema. The tool description adds no additional parameter semantics, thus baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('searches') and a clear resource ('the accessibility tree'), and states the output ('returns elements matching criteria'). This clearly distinguishes it from sibling tools like ui_describe_all or ui_view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like ui_describe_all or ui_tap. It does not mention conditions, exclusions, or preferred scenarios, leaving the agent to infer from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Swipe on the screen in the iOS Simulator
| Name | Required | Description | Default |
|---|---|---|---|
| udid | No | Udid of target, can also be set with the IDB_UDID env var | |
| delta | No | The size of each step in the swipe (default is 1) | |
| x_end | Yes | The ending x-coordinate | |
| y_end | Yes | The ending y-coordinate | |
| x_start | Yes | The starting x-coordinate | |
| y_start | Yes | The starting y-coordinate | |
| duration | No | Swipe duration in seconds (e.g., 0.1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint=false and openWorldHint=true, but the description adds no extra behavioral context. It does not disclose coordinate system, effect on the UI, whether the simulator must be foregrounded, or any side effects. The description is purely nominal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence with no fluff or redundancy. It front-loads the action and resource, making it easy to scan. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7 parameters and no output schema, the description is minimal but not entirely insufficient because the schema covers parameter details. However, it lacks high-level behavioral context (e.g., swipe gesture semantics, coordinate units, delta meaning) that would help an agent know exactly what to expect. This is an adequate-but-gappy description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all parameters (x_start, y_start, x_end, y_end, delta, duration, udid) documented in the input schema. The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Swipe') and resource ('screen in the iOS Simulator'), making the tool's core action clear. However, it does not differentiate from sibling gesture tools like ui_tap or ui_type beyond the action name, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over alternatives. There is no mention of scenarios, prerequisites (e.g., booted simulator), or exclusions. The description simply states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tap on the screen in the iOS Simulator
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | The x-coordinate | |
| y | Yes | The x-coordinate | |
| udid | No | Udid of target, can also be set with the IDB_UDID env var | |
| duration | No | Press duration |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-read-only, open-world operation, but the description adds no behavioral context such as the effect of tapping, coordinate system, or press-and-hold behavior. It merely restates the action without enriching the agent's understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or repetition. It is front-loaded and directly states the action and context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tap tool with a good schema, the description is barely sufficient. It lacks coordinate system details, udid environment variable hints, and any mention of sibling tools. The openWorldHint annotation covers side effects, so the description need not repeat that, but it could benefit from usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 4 parameters (x, y, udid, duration) with 100% coverage, so the baseline of 3 applies. The description itself adds nothing beyond the schema, and there's a minor schema typo (y described as 'x-coordinate') that is not the description's responsibility.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Tap') and resource ('screen') within the iOS Simulator, clearly conveying the tool's core function. It is distinct from siblings like ui_swipe and ui_type, though it does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like ui_type or ui_swipe. The description only states what it does, leaving the agent to infer when tap is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Input text into the iOS Simulator
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to input | |
| udid | No | Udid of target, can also be set with the IDB_UDID env var |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the basic action of inputting text, and the annotations already indicate that this is a non-read-only operation (readOnlyHint false). However, the description adds no additional behavioral context, such as requiring a focused text field or what happens on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that immediately states the tool's function. There is no filler or redundant information, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, a clear schema, and existing annotations, the description is mostly complete. However, it lacks context about prerequisites (e.g., requiring a focused input) and does not mention return values or potential side effects beyond what annotations cover.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both parameters (text and udid), so schema coverage is 100%. The description itself adds no parameter-specific information, and the baseline score of 3 applies when the schema is sufficiently documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Input text into the iOS Simulator' uses a specific verb and resource, clearly indicating the tool types text into the simulator. This distinguishes it from sibling tools like ui_tap and ui_swipe, which handle gestures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for entering text into the simulator but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among the sibling tools. The usage context is clear from the action itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the image content of a compressed screenshot of the current simulator view
| Name | Required | Description | Default |
|---|---|---|---|
| udid | No | Udid of target, can also be set with the IDB_UDID env var |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety contract is known. The description adds behavioral detail by noting the screenshot is compressed and returns image content, which is useful for understanding output expectations without overexplaining.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 11-word sentence that is front-loaded and to the point. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description covers what it returns (image content) and its compression. It lacks explicit details about output encoding or prerequisites (e.g., simulator booted), but these are minor for an agent aware of simulator context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a full description for the single 'udid' parameter, including a pattern and env var alternative. With 100% schema coverage, the description adds no additional parameter information, which is acceptable but doesn't raise the score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves image content of a compressed screenshot for the current simulator view, using a specific verb ('Get') and resource. It distinguishes itself from sibling tools like 'screenshot' by emphasizing 'compressed' and 'image content' rather than a file capture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus sibling tools like screenshot or record_video. The description doesn't mention scenarios or exclusions, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools are clearly distinct: UI interactions, app management, and media capture are well-separated. However, screenshot and ui_view both capture screen content, and ui_describe_all/ui_describe_point/ui_find_element overlap in describing UI elements, though at different granularities.
All tools use snake_case with a verb_noun pattern (e.g., get_booted_sim_id, launch_app). UI actions are consistently prefixed with ui_, and paired operations like record_video/stop_recording follow parallel naming. No mixed conventions or vague verbs.
17 tools is on the heavier side but justifiable for an iOS simulator server that covers device control, UI automation, app management, and media capture. Each tool addresses a specific need and no tool feels redundant enough to remove, though a few are niche, like open_simulator.
Core workflows are covered: app install/launch/terminate, UI interaction, screenshots, video, and deep links. However, there are notable gaps: no simulator shutdown/boot control (only open_simulator), no uninstall_app, and no way to list available simulators or manage the device state beyond booted ID.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Build, run, and inspect iOS apps in disposable hosted Simulators from cloud coding agents.
Control real Android and iOS devices with LLM agents — tap, swipe, type, automate flows.
Cloud iOS simulators and Android emulators your agent can create, drive, and throw away.
Drive real Android & iOS devices and web browsers from natural language for mobile + web QA. 290+ tools across device control, app management, automation sessions, browser automation, and flow recording / replay. Bearer-auth — get a token at robotactions.com → Profile → API Tokens.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/joshuayoes/ios-simulator-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
