Skip to main content
Glama
Sign In
joshuayoes

iOS Simulator MCP

by joshuayoes
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

ui_type

Inputs text into the focused field of an iOS Simulator, supporting key typing or paste for non-ASCII and non-US keyboard layouts.

Instructions

Input text into the iOS Simulator

Input Schema

NameRequiredDescriptionDefault
textYesText to input
udidNoUdid of target, can also be set with the IDB_UDID env var
methodNo"type" (default): presses keys as on a US keyboard; printable ASCII only. "paste": use when the keyboard layout is not US (e.g. AZERTY, where "type" types wrong characters) or the text is non-ASCII; pastes into the focused field (tap it first), ~2-11 stype
replaceNoPaste only: clear the focused field first, e.g. after "type" produced wrong characters

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.2.0
    • addedInput schema / properties / method
      Added value: +{
+  "default": "type",
+  "description": "\"type\" (default): presses keys as on a US keyboard; printable ASCII only. \"paste\": use when the keyboard layout is not US (e.g. AZERTY, where \"type\" types wrong characters) or the text is non-ASCII; pastes into the focused field (tap it first), ~2-11 s",
+  "enum": [
+    "type",
+    "paste"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / replace
      Added value: +{
+  "default": false,
+  "description": "Paste only: clear the focused field first, e.g. after \"type\" produced wrong characters",
+  "type": "boolean"
+}
    • removedInput schema / properties / text / pattern
      Removed value: -"^[\\x20-\\x7E]+$"
  2. Changed2 schema fields changedv2.1.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
  3. First observed

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=false and openWorldHint=true, so the agent knows this mutates simulator state. The description adds nothing beyond that — no mention that text goes to the currently focused field, that 'type' only works on US keyboard layouts, or that paste takes 2-11 seconds. All of that behavior lives only in the schema, leaving the description empty of extra context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with zero waste. It is efficiently sized, though its brevity borders on under-specification rather than deliberate tightness.

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 tool has four parameters, all fully documented in the schema, and no output schema to explain. The description omits the critical operational precondition (tap the target field first) and the layout caveat, but an agent reading the schema will find them, so the gap is moderate rather than fatal.

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%, including enum semantics for 'method' and the interaction with 'replace', so the schema already does the heavy lifting. The description adds no meaning beyond what the schema provides, which is the baseline 3 case.

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?

States a specific verb and resource: 'Input text into the iOS Simulator'. An agent knows exactly what the tool does. However, it does not distinguish itself from siblings like ui_tap or ui_swipe, which also drive the simulator UI, so the boundary is left to inference.

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 offers no when-to-use guidance, no prerequisites (e.g. a field must be focused), and no alternatives. Some guidance exists in the schema's 'method' parameter (type vs paste), but the description itself contributes nothing about selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools