iOS Simulator MCP

by joshuayoes

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.1.0
Disambiguation4/5
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.
Naming Consistency5/5
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.
Tool Count4/5
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.
Completeness3/5
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.
Average 3.7/5 across 17 of 17 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 3 community issues answered or closed in the last 6 months
- No commit activity data available
- Last stable release on August 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ios-simulator-mcp MCP server](https://glama.ai/mcp/servers/joshuayoes/ios-simulator-mcp/badges/card.svg)](https://glama.ai/mcp/servers/joshuayoes/ios-simulator-mcp)

Score Badge

Copy to your README.md:

[![ios-simulator-mcp MCP server](https://glama.ai/mcp/servers/joshuayoes/ios-simulator-mcp/badges/score.svg)](https://glama.ai/mcp/servers/joshuayoes/ios-simulator-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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