IOS MCP SERVER
Point your agent at https://apptelepath.com/mcp and it can read the screen, logs, network calls, sandbox files and SQLite of an iOS app running on a real device — then tap, type and verify.
AppTelepath is a hosted MCP endpoint plus an iOS SDK. Add the URL to your MCP client, then let the agent install the pod. Other iOS MCP servers drive Xcode or the simulator from the outside; this one runs inside your app, on a real device or a simulator.
One HTTPS endpoint and one OAuth grant. No npm package, no stdio process, nothing to keep alive on your Mac.
Add the endpoint to Claude Code or Codex, then let the agent install the pod and start the SDK. It issues its own device credential — you never copy a token.
Simulator MCP servers stop at the UI layer. AppTelepath reads what the app is actually doing: HTTP bodies, UserDefaults, sandbox files, SQLite, crashes, hangs.
Two commands attach the server. One prompt attaches the app.
Both clients take the hosted URL. Authorization opens a browser: you sign in and choose which workspace that client may reach. Grants are per client, and revocable in the console.
CocoaPods or SwiftPM, scoped to your non-App-Store configurations. Hand this step to the agent: with an owner or admin grant it calls telepath_issue_device_token, writes the credential into a gitignored local config, and does not print it back.
Launch the build and have the agent call telepath_list_devices. Once the device is listed, every tool below is live.
# Claude Code claude mcp add --transport http apptelepath https://apptelepath.com/mcp # then run /mcp inside Claude Code to authorize # Codex CLI / Codex App codex mcp add apptelepath --url https://apptelepath.com/mcp \ --oauth-client-id https://apptelepath.com/oauth/clients/codex-cli.json codex mcp login apptelepath
pod 'AppTelepath', '~> 3.0', :configurations => ['Debug', 'Staging'] # React Native Fabric hosts: # pod 'AppTelepath/ReactNative', '~> 3.0', :configurations => ['Debug', 'Staging']
The legacy pod name Telepath installs the exact same binary — pick one, not both. React Native Fabric hosts use AppTelepath/ReactNative so Pressable can be activated. Either way the import stays import Telepath.
.package(url: "https://github.com/AppTelepath/AppTelepath-iOS.git", from: "3.1.0")
SwiftPM hosts must add -ObjC to Other Linker Flags themselves. CocoaPods adds it automatically; SwiftPM forbids a dependency from doing it for you, and without it the SDK's categories are dropped at link time.
#if TELEPATH_ENABLED import Telepath Telepath.start() #endif
Define TELEPATH_ENABLED in the configurations you want debuggable — not DEBUG, since TestFlight and Ad Hoc builds are Release-class. App Store builds are detected at runtime and refuse to start; TestFlight needs an explicit opt-in.
The same workspace is reachable over plain HTTP and SSE — /api/devices, /api/screenshot, /api/invoke, /api/events — so scripts and CI jobs can debug with curl.
curl -s -H "Authorization: Bearer $TOKEN" https://apptelepath.com/api/devices
Every tool is deterministic: the server compresses and aligns device facts, your agent does the reasoning. There is no model inference in the middle.
Screen digests cost a fraction of a screenshot's tokens, and every element carries a stable ref you pass straight to an action.
telepath_list_devices — connected devices, app info, supported commands
telepath_screen_digest — text digest of the screen: view controller, interactive elements, visible text
telepath_screenshot — the rendered screen as an image
telepath_view_hierarchy — flat summary with refs by default; full nested tree on request
telepath_ui_diff — what changed since a baseline you pass back in
telepath_app_info — bundle, version, memory, CPU, sandbox paths, permission states
telepath_device_time — device clock and its skew from your machine
This is the layer an outside-in MCP server cannot reach: real request bodies, the app's own defaults, its sandbox and its database.
telepath_get_logs — recent console output, filtered
telepath_wait_for_log — wait until a matching line appears, or time out
telepath_network_requests — captured HTTP calls with status, timing and sizes
telepath_network_request_detail — headers and bodies, paged for large payloads
telepath_list_files — sandbox directory listing
telepath_read_file — read a sandbox file, text or base64, paged
telepath_user_defaults — dump, get, set, delete
telepath_db_query — SQLite files, tables, arbitrary SQL
Actions report what changed on screen plus the errors and failed requests logged during them, so a confirming screenshot is usually unnecessary.
telepath_tap — tap by ref, accessibility id, label or point
telepath_swipe — scroll or drag, and which path actually delivered it
telepath_input_text — type through the real editing lifecycle, not a value assignment
telepath_invoke — escape hatch for any raw device command, including ones your app registers
Crash, hang, leak and thread detectors are off until armed, and report monitoring:false rather than an empty list that reads like "no problems found".
telepath_diagnose — one call: clustered errors, failed requests, crashes and hangs, ranked
telepath_recent_timeline — merged log, network and crash timeline after the fact — no recording needed
telepath_performance — CPU, memory, FPS, thread count
telepath_crash_reports — recorded crashes with full stacks
telepath_hangs — main-thread freezes, with the stack captured at the freeze
telepath_leaks — retain cycles proven by reference graph; unproven suspects stay separate
telepath_thread_health — thread explosions and UIKit calls off the main thread
telepath_trace_methods — scoped method trace whose caller hints survive stripped builds
Recording a session gives people and agents the same timeline to review — and the console replays it panel by panel.
telepath_repro — record, run an action sequence, stop, return the timeline — in one call
telepath_replay_request — resend a captured request through the app's own network stack
telepath_start_recording — session timeline with optional periodic screenshots
telepath_stop_recording — stop the session
telepath_list_recordings — recordings stored for this workspace
telepath_get_recording — fetch a timeline, filtered by event type
Location, push and weak network in one tool. Each reports the parameters actually in effect, so an agent never has to guess what "slow" means.
telepath_simulate location — coordinates, routes at a given speed, failures, forged authorization state
telepath_simulate push — payloads, silent pushes, notification taps and action buttons
telepath_simulate weaknet — latency, bandwidth, failure rate, status codes, hung requests, scoped by URL
Two more tools appear only under an owner or admin grant: telepath_issue_device_token and telepath_revoke_device_token. They create or rotate a device-only credential that can open a device connection and nothing else — it cannot call MCP, HTTP or controller APIs, which is why an agent may write it into a local build config without handing your workspace to a test build.
The server also publishes an MCP resource, telepath://guide, so clients that read resources pick the right tool on first contact.
Most of them work on the build, the simulator or the UI from the outside. AppTelepath works inside the running app. For most teams the answer is both, not one.
| AppTelepath | XcodeBuildMCP | mobile-mcp | ios-simulator-mcp | Xcode built-in MCP | |
|---|---|---|---|---|---|
| Physical device | Yes — device or simulator, same tools | Yes, USB or Wi-Fi | Yes, with extra setup | Simulator only | Whatever Xcode is driving locally |
| Local Xcode required | To build the app, yes; to debug it, no | Yes — macOS 14.5+, Xcode 16+ | Yes, for the iOS toolchain | Yes | Yes — it is Xcode |
| WebDriverAgent or device tunnel | No — the SDK is already in the build | No — Apple toolchain, code signing in Xcode | Yes — WebDriverAgent, go-ios, device tunnel | No — simulator only | No |
| Hosted remote MCP | Yes — one URL, OAuth per client | No — runs locally | No — runs locally | No — runs locally | No — runs on your Mac |
| In-app runtime state | Yes — network bodies, UserDefaults, sandbox, SQLite, crashes, hangs | Build, run and debugger layer | UI layer | UI and simulator layer | Build, test, preview and debugger layer |
XcodeBuildMCP is the strongest tool in its layer. Sentry maintains it, it exposes 82 tools across build, run, test and LLDB, and it drives physical devices over USB or Wi-Fi. Xcode 26.3 now ships its own MCP server over the same territory: build system, simulator, previews, debugger. Both answer "did it compile, launch and pass".
AppTelepath answers the next question: what did the app do once it was running. Different layer, different failure modes — an agent that has both builds and installs through the Xcode-layer server, then reads the app's own logs, requests and database through this one. Argent (Software Mansion) and ios-simulator-mcp are deliberately simulator-only, which is a reasonable scope when a simulator is all you need.
The home page runs the actual tool output — digest, tap, network, diagnose — with no sign-up.
Live demoThree limits worth knowing before you spend a minute on setup.
The iOS SDK is the only one published. Android and a full React Native JS probe are on the roadmap, not in your hands. Nothing here works on a platform we have not shipped.
The SDK detects the distribution channel and refuses to start in App Store builds. TestFlight requires an explicit opt-in and the acceptance that an embedded device credential can be extracted.
There is no npm package, no stdio server and no self-hosted distribution. The endpoint is https://apptelepath.com/mcp; anything else claiming to be a Telepath MCP package is not ours.
The hosted service and the iOS SDK are free during the Beta. Trial device, traffic, seat and retention limits apply, but a workspace does not expire by time. Paid plans are not active.
Building the app does. Debugging it does not: the SDK is compiled into your build, and from then on the app connects outward to the hosted relay. Your agent only talks HTTPS to the MCP endpoint, so it can run anywhere, including CI.
Yes, and a real device is not a special case — the SDK connects outward over WebSocket, so there is no WebDriverAgent to install, no tunnel to keep open and no USB session to babysit. Simulators use the exact same tools.
No. AppTelepath is hosted only, at https://apptelepath.com/mcp, and OAuth 2.1 identifies each client by a client ID metadata document rather than anonymous dynamic registration. Agents without MCP support can use the HTTP and SSE API instead.
No. It detects the distribution channel at runtime and refuses to start in App Store builds. TestFlight requires an explicit opt-in. If one configuration is used for both archives and testing, keep it empty, exclude the SDK, and create a separate Internal or Staging configuration.
Each MCP client authorizes once in the browser: you sign in and choose the workspace that client may reach. Grants are per client, and the console lists and revokes them under Workspace settings, Authorized AI agents. Device credentials issued to an app are revoked with telepath_revoke_device_token.
Nothing during the free Beta. Trial device, traffic, seat and retention limits apply, but the workspace does not expire by time. Paid plans are not active yet.
Free Beta. Two commands, one pod, and the next bug report is a tool call instead of a screenshot.
Start freeRelated: AppTelepath overview · Pricing