Local MCP server for iOS Simulator and macOS app automation with a native Swift bridge
Copy the AI prompt to install this server into Claude Code, Cursor, or another agent β or use 1-click editor setup below.
We haven't yet run this listing's install command through our automated sandbox check. This isn't a red flag β we're steadily working through the catalog.
π‘ Paste the JSON block into your client's configuration file under mcpServers, then restart the application.
Inspect callable tools, capabilities, and parameters exposed to AI agents by Baepsae.
pasteCallable MCP tool function
keyboardCallable MCP tool function
Baepsae (Vinous-throated Parrotbill) β A tiny Korean bird. Round, chubby, and constantly hopping around chirping. Known for its grit β even when a little bird tries to keep up with a stork, it never gives up. This project is small too, but it pecks away at your simulators tirelessly.
Local MCP server for iOS Simulator and macOS app automation with a TypeScript MCP layer and a Swift native bridge.
νκ΅μ΄ λ¬Έμλ README-KR.mdλ₯Ό μ°Έκ³ νμΈμ.
| Platform | Supported | Notes |
|---|---|---|
| macOS | Yes | Primary platform. Required for iOS Simulator and Accessibility APIs. |
| Linux | No | Native binary depends on AppKit, CoreGraphics, and Accessibility frameworks. |
| Windows | No | Native binary depends on AppKit, CoreGraphics, and Accessibility frameworks. |
Why macOS only?
The Swift native bridge (baepsae-native) uses macOS-specific frameworks (AppKit, CoreGraphics, Accessibility) to interact with iOS Simulator and macOS applications. These frameworks are not available on Linux or Windows. The TypeScript MCP layer also relies on xcrun simctl, which is part of Xcode Command Line Tools and only available on macOS.
Requirements summary:
xcrun simctl commands.Accessibility permission is required for UI inspection and input automation features (use unified generic tools such as analyze_ui, tap, right_click).
The important detail is that permission usually needs to be granted to the automation host / runtime process, not to the target app you are automating.
baepsae-native ...baepsae-native binary itself, plus the terminal/shell app that launched itnode dist/index.js, npx -y mcp-baepsae@latestnode), plus the terminal or MCP client app that launched itnode, bun, etc.).baepsae-native binary entry if it appears separately.+ and add it manually.After granting permission, the launching process may need to be restarted before macOS applies the change.
If the error persists, quit and relaunch the terminal, MCP client, or runtime process that started mcp-baepsae.
For simulator targets, selector-based actions (tap / right_click with id or label) search in-app content by default. Set all: true to include Simulator chrome UI.
On macOS, the Swift native binary is built automatically during install. If Swift is not available, the server still works with simctl-based features.
If you plan to use UI inspection or input automation right away, grant Accessibility permission to the terminal / MCP client / runtime process you will actually launch the server with.
Use the installer script that calls each client's MCP install flow directly.
| Client | Install Path | Script Target | Notes |
|---|---|---|---|
| Claude Code | claude mcp add | --tool claude-code | Supports multi-scope via --claude-scope |
| Claude Desktop | claude mcp add --scope user | --tool claude-desktop | User-level registration |
| Codex CLI | codex mcp add | --tool codex-cli | Also works for Codex Desktop settings |
| Codex Desktop | Codex CLI MCP config | --tool codex-desktop | Uses same MCP registry as CLI |
| OpenCode | Global config (~/.config/opencode/opencode.json) | --tool opencode | Auto-updated by installer |
| Gemini | gemini mcp add | --tool gemini | User scope setup |
| Google Antigravity | Gemini-compatible MCP flow | --tool antigravity | Uses Gemini MCP command path |
| GitHub Copilot | copilot or gh copilot session | --tool copilot | Interactive/session-based setup |
If you are an LLM agent setting up this MCP server, here is everything you need:
Before trying UI automation tools, remember that Accessibility permission usually belongs to the host/runtime process (
node, terminal, MCP client), not the target app under automation.
If you installed via npm instead of cloning the repo, use npx:
The installer supports multiple runtimes via --runtime:
| Flag | Command | When to use |
|---|---|---|
--runtime node (default) | node dist/index.js | Local source build |
--runtime npx | npx -y mcp-baepsae@latest | npm registry, no global install |
--runtime bunx | bunx mcp-baepsae@latest | Bun users |
--runtime global | mcp-baepsae | After npm install -g mcp-baepsae |
Use this when you do not want to run scripts/install.sh.
When using npx, the relevant Accessibility entry is commonly the spawned node runtime plus the terminal / MCP client that launched it.
When using a local build, check permission on both the runtime (node) and the app that launched it.
If you invoke baepsae-native directly for debugging, check permission on the native binary entry itself as well.
src/index.tssrc/tools/ (info, simulator, ui, input, media, system)src/utils.ts, src/types.tsnative/Sources/main.swiftnative/Sources/Commands/native/.build/release/baepsae-nativetests/mcp.contract.test.mjs, tests/unit.test.mjs, tests/mcp.real.test.mjsnative/Tests/BaepsaeNativeTests/43 tools implemented end-to-end.
The public API surface is intentionally single-scheme: use unified generic tools with a target argument, rather than sim_* / mac_* names.
Factual signals from GitHub, npm, and our automated checks β not a rating.
No reviews yet β be the first to share how this listing worked for you.
Showcase your server listing on GitHub or your project documentation. Embed this dynamic SVG badge to highlight official listing status and live engagement.
[](https://allmcps.com/mcp/baepsae)<a href="https://allmcps.com/mcp/baepsae"><img src="https://allmcps.com/api/badge/baepsae?style=directory" alt="Baepsae on AllMCPs" /></a>