The direct UDID tools are the ones to reach for — list, boot, use, shut down, no state to keep straight. The session layer earns its place only when you need to refer to a simulator by a name you chose or carry metadata alongside it, and the project says as much.
A stdio server over appium-ios-simulator that manages simulator instances and drives what runs inside them.
- list-available-simulators and list-booted-simulators show what exists and what is running, with UDIDs
- boot-simulator-by-udid and shutdown-simulator-by-udid work directly on a device, no session bookkeeping
- install-app, launch-app and terminate-app put a build on the simulator and control it
- take-screenshot returns the simulator screen; tap-coordinate taps at a point
- A session layer for tracking simulators by your own IDs — create-simulator-session, create-and-boot-simulator, boot-simulator, shutdown-simulator, list-simulator-sessions and terminate-simulator-session
- Multiple simulator sessions at once, with logging written to file rather than stdout so the transport stays clean
macOS with Xcode and its simulators installed — simulators do not run anywhere else. Node.js v16 or later; clone, npm install, npm run build, then point the client at dist/index.js. SIMULATOR_DEFAULT_DEVICE, SIMULATOR_DEFAULT_OS and SIMULATOR_TIMEOUT set the defaults. The Docker image can host the MCP process for portability but cannot drive a real simulator.
One command — npx -y @smithery/cli install @atom2ueki/mcp-server-ios-simulator --client claude