
Baepsae
io.github.oozoofrogPublished by GitHub account oozoofrogv6.3.0Updated Oct 24, 2026
Local MCP server for iOS Simulator and macOS app automation with a native Swift bridge
Overview
A local MCP server that lets an assistant inspect and drive iOS Simulators and macOS apps through a native Swift bridge.
- What you can do
- Inspect and query the UI accessibility tree, then tap, type, swipe, scroll, drag and set values by identifier or label, including tab switching and dialog detection with a wait step for UI changes and a run_steps workflow tool for chaining actions. Send keyboard input, key sequences and key combos, touch input, and list or switch input sources. Manage simulators: list devices, take screenshots, record or stream video, open URLs, and install, launch, terminate or uninstall apps. Work with macOS apps and windows: list apps and windows, activate or focus a window, screenshot an app, right-click, use context menus and menu actions, read the clipboard, and watch notifications. Run diagnostics: a
- When to use it
- Useful when you are developing or testing iOS apps in the Simulator or automating macOS apps on your own Mac, and want an assistant to inspect the UI, drive taps and typing, capture screenshots or video, and manage app installs and launches. It is macOS-only, so it is not an option on Linux or Windows.
- Requirements
- macOS 14 or later with Xcode or Xcode Command Line Tools (for xcrun simctl and Swift 6+ to build the native binary), plus Node.js 18 or later; installable via npx or npm. Accessibility permission must be granted to the launching terminal, MCP client or runtime process (node), and the process may need a restart afterwards. A booted simulator is needed for simulator features.
Installation
In SourceWeft
- Open Baepsae in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
mcp-baepsae
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를 참고하세요.
Table of Contents
- Prerequisites
- Platform Support
- Install
- Permissions
- MCP Setup (Recommended)
- Client Matrix
- For LLM
- Manual Setup (Fallback)
- Project Structure
- Commands
- MCP Tool Status
- Usage Examples
- Troubleshooting
Prerequisites
- macOS 14+
- Xcode + iOS Simulator
- Node.js 18+
- Swift 6+
Platform Support
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:
- macOS 14 or later -- required for iOS Simulator automation and Accessibility API access.
- Xcode or Xcode Command Line Tools -- required for Swift 6+ compilation of the native binary and
xcrun simctlcommands. - Node.js >= 18.0.0 -- required to run the TypeScript MCP server.
Permissions
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.
Which process usually needs permission?
- Direct native binary invocation
- Example:
baepsae-native ... - Most relevant entry: the
baepsae-nativebinary itself, plus the terminal/shell app that launched it
- Example:
- Node / npx MCP runtime
- Example:
node dist/index.js,npx -y mcp-baepsae@latest - Most relevant entry: the runtime process (
node), plus the terminal or MCP client app that launched it
- Example:
- Desktop / CLI MCP clients
- Example: Claude Code, Codex CLI/Desktop, Gemini CLI
- Relevant entries can include the MCP client app, the terminal host, and the runtime process depending on launch path
Recommended setup flow
- Open System Settings > Privacy & Security > Accessibility.
- Enable the terminal or MCP client app you actually use.
- Enable the runtime process if listed (
node,bun, etc.). - For direct native invocation, also enable the
baepsae-nativebinary entry if it appears separately. - If an entry is missing, click
+and add it manually.
Important note
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.
Install
Option A) npm (easiest)
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.
Option B) From source
MCP Setup (Recommended)
Use the installer script that calls each client's MCP install flow directly.
Client Matrix
For LLM
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.
Quick start (one command)
If you installed via npm instead of cloning the repo, use npx:
Automation flags
Runtime options
The installer supports multiple runtimes via --runtime:
Manual Setup (Fallback)
Use this when you do not want to run scripts/install.sh.
Using npx (recommended for npm users)
When using npx, the relevant Accessibility entry is commonly the spawned node runtime plus the terminal / MCP client that launched it.
Using local build
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.
Project Structure
- MCP server entry point:
src/index.ts - Tool modules:
src/tools/(info, simulator, ui, input, media, system) - Shared utilities:
src/utils.ts,src/types.ts - Native binary entry point:
native/Sources/main.swift - Native command handlers:
native/Sources/Commands/ - Native binary output:
native/.build/release/baepsae-native - TS tests:
tests/mcp.contract.test.mjs,tests/unit.test.mjs,tests/mcp.real.test.mjs - Swift tests:
native/Tests/BaepsaeNativeTests/
Commands
MCP Tool Status
43 tools implemented end-to-end.
Official public MCP surface: unified generic tools
The public API surface is intentionally single-scheme: use unified generic tools with a target argument, rather than sim_* / mac_* names.
Target routing is explicit in the arguments: udid for simulator, bundleId / appName for macOS.
type_text policy
type_text accepts exactly one input source: text, stdinText, or file.
method: "auto"resolves to:pastefor simulator targetskeyboardfor macOS targets
method: "paste"uses the simulator pasteboard for simulator targets and a temporary host clipboard replace/restore flow for macOS targets.method: "keyboard"always types character-by-character.
When paste is used, simulator targets update the simulator pasteboard without touching the host clipboard, while macOS targets temporarily overwrite the host clipboard and restore it after submission. Successful responses report the input source, target kind, requested method, used method, paste transport, and any auto fallback that was applied.
tap_tab policy
tap_tab is semantic-first, geometry-last.
- First it tries actionable descendants exposed under the tab bar.
- If SwiftUI/Simulator does not expose real tab button descendants, it can use a semantic proxy row (for example, app-provided top navigation buttons that map cleanly to the same tabs).
- Only if neither semantic path exists does it fall back to tab-bar geometry.
This matters because SwiftUI TabView in Simulator may expose the tab bar as a generic AXGroup text="Tab Bar" without actionable child buttons.
Usage Examples
Switch tabs by index with semantic-first fallback:
Unified simulator app accessibility quickstart (inside app UI):
Open a URL (iOS Simulator):
Manage Apps (iOS Simulator):
macOS App Automation:
Troubleshooting
Accessibility permission checklist
-
The permission target is usually the automation host/runtime process, not the target app.
-
Run
doctorfirst to inspect host process, parent process, native binary, booted simulator availability, and accessibility readiness in one place. -
Check the error message for:
- current host process
- parent process
- inferred launch mode
-
If you launched through
npx/node, grant permission to the runtime and the launching terminal / MCP client. -
If you launched
baepsae-nativedirectly, grant permission to the native binary entry and the launching terminal / shell app. -
After changing permission, restart the launching process before retrying.
-
Invalid environment variable formaton Claude setup:- Use current script (
scripts/install.sh) orclaude mcp add --env="KEY=value" ...format.
- Use current script (
-
Missing native binaryerror:- Run
npm run buildand confirmnative/.build/release/baepsae-nativeexists.
- Run
-
Accessibility permission error is ambiguous:
- Current versions include host/parent process diagnostics and inferred launch mode in the error text so you can see which executable path likely needs permission.
-
Real smoke test diagnostics:
- Run
npm run test:real:preflightto print environment and capability diagnostics without executing the full suite. - Run
npm run test:real:simto focus on simulator-capability coverage, ornpm run test:real:macfor the macOS Safari subset.
- Run
-
Multiple Simulator windows are open and selectors hit the wrong device:
- Current versions scope simulator selectors to the target
udidwindow first. - If you intentionally need Simulator chrome/system UI, use
all: true.
- Current versions scope simulator selectors to the target
-
OpenCode does not show
baepsae:- Re-run
bash scripts/install.sh --tool opencode --skip-install --skip-buildand check~/.config/opencode/opencode.json.
- Re-run
-
Copilot not auto-registered:
- Copilot MCP flow is interactive/session-based. Re-run installer with
--interactive.
- Copilot MCP flow is interactive/session-based. Re-run installer with
-
Real smoke test skipped:
- Boot an iOS simulator first, then run
npm run test:real.
- Boot an iOS simulator first, then run
Source: README.md at commit 4e36492
Tools
0Version history
1- v6.3.0LatestSep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts