Un servidor del Protocolo de Contexto de Modelo (MCP) para interactuar con simuladores de iOS. Este servidor le permite interactuar con simuladores de iOS obteniendo información sobre ellos, controlando las interacciones de la interfaz de usuario e inspeccionando elementos de la interfaz.
Aviso de seguridad: Se han corregido las vulnerabilidades de inyección de comandos presentes en versiones anteriores a la 1.3.3. Por favor, actualice a la versión 1.3.3 o posterior. Consulte SECURITY.md para más detalles.
https://github.com/user-attachments/assets/453ebe7b-cc93-4ac2-b08d-0f8ac8339ad3
Este proyecto ha sido destacado y mencionado en diversas publicaciones y recursos:
Artículo de mejores prácticas de Claude Code - Blog de ingeniería de Anthropic que muestra las mejores prácticas
React Native Newsletter Issue 187 - Destacado en el boletín informativo más popular de la comunidad de React Native
Mobile Automation Newsletter - #56 - Destacado en un boletín de larga trayectoria sobre pruebas móviles y recursos de automatización
Listado en punkeye/awesome-mcp-server - Incluido en una de las colecciones más populares de servidores MCP seleccionados
Related MCP server: iOS Device Control MCP Server
get_booted_sim_idDescripción: Obtiene el ID del simulador de iOS que se está ejecutando actualmente
Parámetros: Sin parámetros
open_simulatorDescripción: Abre la aplicación del Simulador de iOS
Parámetros: Sin parámetros
ui_describe_allDescripción: Describe la información de accesibilidad de toda la pantalla en el Simulador de iOS
Parámetros:
{
/**
* 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_tapDescripción: Toca la pantalla en el Simulador de iOS
Parámetros:
{
/**
* 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_typeDescripción: Introduce texto en el Simulador de iOS
Parámetros:
{
/**
* 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_swipeDescripción: Desliza el dedo por la pantalla en el Simulador de iOS
Parámetros:
{
/**
* 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_pointDescripción: Devuelve el elemento de accesibilidad en las coordenadas indicadas en la pantalla del Simulador de iOS
Parámetros:
{
/**
* 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_elementDescripción: Busca en el árbol de accesibilidad y devuelve los elementos que coinciden con los criterios dados
Parámetros:
{
/** 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_viewDescripción: Obtiene el contenido de la imagen de una captura de pantalla comprimida de la vista actual del simulador
Parámetros:
{
/**
* Udid of target, can also be set with the IDB_UDID env var
* Format: UUID (8-4-4-4-12 hexadecimal characters)
*/
udid?: string;
}screenshotDescripción: Toma una captura de pantalla del Simulador de iOS
Parámetros:
{
/**
* 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_videoDescripción: Graba un vídeo del Simulador de iOS usando simctl directamente
Parámetros:
{
/**
* 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_recordingDescripción: Detiene la grabación de vídeo del simulador usando killall
Parámetros: Sin parámetros
install_appDescripción: Instala un paquete de aplicación (.app o .ipa) en el Simulador de iOS
Parámetros:
{
/**
* 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_appDescripción: Inicia una aplicación en el Simulador de iOS mediante el identificador del paquete
Parámetros:
{
/**
* 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>;
}Notas: Las variables de entorno se pasan usando SIMCTL_CHILD_ porque simctl launch no admite --env/--envs en todas las versiones de Xcode.
Ejemplo:
{
"bundle_id": "com.example.app",
"terminate_running": true,
"env": {
"FOO": "bar",
"BAZ": "qux"
}
}Este servidor MCP permite a los asistentes de IA integrados con un cliente del Protocolo de Contexto de Modelo (MCP) realizar tareas de Aseguramiento de Calidad (QA) mediante llamadas a herramientas. Esto es útil inmediatamente después de implementar funciones para ayudar a garantizar la consistencia de la interfaz de usuario y un comportamiento correcto.
Después de implementar una función, indique a su asistente de IA dentro de su entorno de cliente MCP que utilice las herramientas disponibles. Por ejemplo, en el modo agente de Cursor, podría usar las siguientes instrucciones para validar y documentar rápidamente las interacciones de la interfaz de usuario.
Verificar elementos de la interfaz:
Verify all accessibility elements on the current screenConfirmar entrada de texto:
Enter "QA Test" into the text input field and confirm the input is correctComprobar respuesta al toque:
Tap on coordinates x=250, y=400 and verify the expected element is triggeredValidar acción de deslizamiento:
Swipe from x=150, y=600 to x=150, y=100 and confirm correct behaviorComprobación detallada de elementos:
Describe the UI element at position x=300, y=350 to ensure proper labeling and functionalityMostrar la pantalla del simulador a su agente de IA:
View the current simulator screenTomar captura de pantalla:
Take a screenshot of the current simulator screen and save it to my_screenshot.pngGrabar vídeo:
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`)Detener grabación:
Stop the current simulator screen recordingInstalar aplicación:
Install the app at path/to/MyApp.app on the simulatorIniciar aplicación:
Launch the Safari app (com.apple.mobilesafari) on the simulatorNode.js
macOS (ya que los simuladores de iOS solo están disponibles en macOS)
Xcode y simuladores de iOS instalados
Herramienta IDB de Facebook (ver guía de instalación)
Esta sección proporciona instrucciones para integrar el servidor MCP del Simulador de iOS con diferentes clientes del Protocolo de Contexto de Modelo (MCP).
Cursor gestiona los servidores MCP a través de su archivo de configuración ubicado en ~/.cursor/mcp.json.
Edite su archivo de configuración MCP de Cursor. A menudo puede abrirlo directamente desde Cursor o usar un comando como:
# Open with your default editor (or use 'code', 'vim', etc.)
open ~/.cursor/mcp.json
# Or use Cursor's command if available
# cursor ~/.cursor/mcp.jsonAñada o actualice la sección mcpServers con la configuración del servidor del simulador de iOS:
{
"mcpServers": {
// ... other servers might be listed here ...
"ios-simulator": {
"command": "npx",
"args": ["-y", "ios-simulator-mcp"]
}
}
}Asegúrese de que la estructura JSON sea válida, especialmente si mcpServers ya existe.
Reinicie Cursor para que los cambios surtan efecto.
Clone este repositorio:
git clone https://github.com/joshuayoes/ios-simulator-mcp
cd ios-simulator-mcpInstale las dependencias:
npm installCompile el proyecto:
npm run buildEdite su archivo de configuración MCP de Cursor (como se muestra en la Opción 1).
Añada o actualice la sección mcpServers, apuntando a su compilación local:
{
"mcpServers": {
// ... other servers might be listed here ...
"ios-simulator": {
"command": "node",
"args": ["/full/path/to/your/ios-simulator-mcp/build/index.js"]
}
}
}Importante: Reemplace /full/path/to/your/ con la ruta absoluta a donde clonó el repositorio ios-simulator-mcp.
Reinicie Cursor para que los cambios surtan efecto.
La CLI de Claude Code puede gestionar servidores MCP usando los comandos claude mcp o editando sus archivos de configuración directamente. Para obtener más detalles sobre la configuración de MCP en Claude Code, consulte la documentación oficial.
Añada el servidor usando el comando claude mcp add:
claude mcp add ios-simulator npx ios-simulator-mcpReinicie cualquier sesión de Claude Code en ejecución si es necesario.
Clone este repositorio, instale las dependencias y compile el proyecto como se describe en los pasos 1-3 de "Desarrollo local" de Cursor.
Añada el servidor usando el comando claude mcp add, apuntando a su compilación local:
claude mcp add ios-simulator -- node "/full/path/to/your/ios-simulator-mcp/build/index.js"Importante: Reemplace /full/path/to/your/ con la ruta absoluta a donde clonó el repositorio ios-simulator-mcp.
Reinicie cualquier sesión de Claude Code en ejecución si es necesario.
Variable | Descripción | Ejemplo |
| Una lista separada por comas de nombres de herramientas para filtrar y evitar que se registren. |
|
| Especifica un directorio predeterminado para archivos de salida como capturas de pantalla y grabaciones de vídeo. Si no se establece, se usará |
|
| Especifica una ruta personalizada al ejecutable IDB. Si no se establece, se usará |
|
{
"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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v2.1.0install_app2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falselaunch_app3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / env / propertyNamesAdded value: +{
+ "type": "string"
+}list_appsopen_urlrecord_video2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falsescreenshot2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falsestop_recording1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"terminate_appui_describe_all2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseui_describe_point2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseui_find_element2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseui_swipe2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseui_tap2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseui_type2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseui_view2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falsev1.6.0launch_app1 field changedInput schema / properties / envAdded value: +{
+ "additionalProperties": {
+ "type": "string"
+ },
+ "description": "Environment variables to pass to simctl launch",
+ "type": "object"
+}record_video1 field changedInput schema / properties / udidAdded value: +{
+ "description": "Udid of target, can also be set with the IDB_UDID env var",
+ "pattern": "^[0-9A-Fa-f]{8}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{12}$",
+ "type": "string"
+}stop_recording1 field changedInput schema / additionalPropertiesRemoved value: -falseui_find_elementv1.0.0install_applaunch_appopen_simulatorui_swipe1 field changedInput schema / properties / durationAdded value: +{
+ "description": "Swipe duration in seconds (e.g., 0.1)",
+ "pattern": "^\\d+(\\.\\d+)?$",
+ "type": "string"
+}get_booted_sim_idrecord_videoscreenshotstop_recordingui_describe_allui_describe_pointui_swipeui_tapui_typeui_viewMost 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
