Loading ToolBench
An MCP server for building and running iOS apps in Xcode, and controlling iOS Simulators
Xcode Studio MCP has 6 well-named tools with action verbs and clear descriptions. Most parameters have type definitions and descriptions. However, output schemas are NOT documented, a critical omission. The server lacks error recovery guidance (tools throw NSError without actionable advice for LLMs). Parameter validation is implicit but not documented (e.g., 'duration' for tap has no bounds). Tool descriptions are adequate but could be more explicit about prerequisites, return structures, and when to use each tool vs alternatives. No parameters are missing, but output field documentation is absent, forcing LLMs to infer result structure.
Get the accessibility tree of the current iOS Simulator screen as JSON. Useful for finding UI elements to interact with. Requires idb (pip3 install fb-idb).
Capture a screenshot of the iOS Simulator screen. Returns the image as base64-encoded PNG.
Tap at specific coordinates on the iOS Simulator screen. Requires idb (pip3 install fb-idb).
Type text into the currently focused field on the iOS Simulator. Requires idb (pip3 install fb-idb).
Build an Xcode project or workspace. Returns structured diagnostics with file, line, column, severity, and message for each error/warning.
Build an Xcode project and launch the app in the iOS Simulator. Returns build errors if the build fails, or a success message with the launched process ID.
Output schemas are completely undocumented. LLMs cannot infer what fields are returned by tools. For example, xcode_build returns a BuildResult object, but the schema (succeeded, diagnostics, summary, rawOutput fields) is invisible in tool definitions and only visible in source code implementation. This violates pattern:response-shaper and forces LLMs to guess what data is available.
Error handling provides no recovery guidance. All 6 tools throw NSError with minimal context. When a tool fails (e.g., 'Screenshot failed: permission denied'), LLMs receive no actionable next steps, no suggestion to check simulator state, no retry guidance, no alternative tool recommendations. Violates pattern:recovery-guide.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
Prerequisite dependencies not documented in descriptions. simulator_tap and simulator_type require idb (pip3 install fb-idb) but the descriptions mention this only as a terse note. No guidance on 'if idb is not installed, follow these steps' or 'error recovery if idb fails'. Users/LLMs have no context for troubleshooting missing dependencies.
Parameter constraints are implicit, not declared. 'duration' parameter in simulator_tap has no documented minimum/maximum bounds. 'x' and 'y' coordinates have no validation range (0-width, 0-height?). 'configuration' in xcode_build defaults to 'Debug' but no enum is declared for valid values (Debug, Release, etc.). Violates pattern:constrained-input.
Tool composition chains are unclear. No documentation of which tools should be called in sequence. For example, should agent call simulator_describe first to locate UI elements, then simulator_tap to interact? Or should it call simulator_screenshot to debug failures? No guidance on workflow or sequencing.
simulator_run and xcode_build descriptions do not specify result limits or truncation behavior. What happens if xcodebuild output is 50MB? Are diagnostics capped? Is raw output included? No pagination or limit parameters despite potentially large outputs.