Xcode MCP: Setting It Up for Claude Code, and What I Saw
The three steps and one command Apple documents for external agents, then four things I observed on Xcode 27.0 that the page does not say.
If you want Claude Code to build your iOS project and act on it through Xcode itself, Xcode MCP is the route Apple documents for this: Xcode runs an MCP server, and an agent you launch outside Xcode connects to it through xcrun mcpbridge. Apple's page is short. This post quotes it, then adds four things I saw on Xcode 27.0 that the page does not cover.
Updated 2026-10-26. Apple's Giving external agents access to Xcode was read on 2026-10-26. My observations are from 2026-09-29 on Xcode 27.0 (27A266a); a newer Xcode may behave differently.
What Apple documents
The page's summary is that you can "give permission for external agents, that you launch outside of Xcode, to modify your Xcode project and perform actions, such as building your app." It lists three steps: allow the agent access to Xcode in Intelligence settings, configure the agent to reach Xcode through the MCP server, and open your project in Xcode before prompting the agent.
The setting is under Xcode > Settings > Intelligence, in the Model Context Protocol section: turn on "Allow external agents to use Xcode tools." The command it gives for Claude Code is:
claude mcp add --transport stdio xcode -- xcrun mcpbridge
For Codex the page gives codex mcp add xcode -- xcrun mcpbridge, and says to check the result with claude mcp list or codex mcp list. It also suggests optional hints about Xcode and your project in AGENTS.md or CLAUDE.md. The page says Xcode "alerts you when the external agent connects to Xcode and when it's active." I did not test that alert wording.
What I saw on Xcode 27.0
I ran the same wiring, with one difference: I added --scope user so the server is available in every project. Apple's page does not mention scope, and I make no claim about the default.
Four things I saw on 2026-09-29 are not on Apple's page, and each comes from one machine, not a rule.
| # | What I saw | What I know about the cause |
|---|---|---|
| 1 | The server listed 56 tools: build, run and test, build log, compiler issues, preview render, build settings, project editing, a debugger, and a set of DeviceInteraction tools | The count is from my own list on that date; I did not compare it with other Xcode versions |
| 2 | In my run the project did not need to be open in Xcode when I passed its absolute path to the server, which ran as a background service | Observed; I did not read how it is implemented |
| 3 | The DeviceInteraction tools (tap, swipe, type, screenshot, UI hierarchy) worked on an iOS 27 simulator, the only target I ran them on (I did not test watchOS or tvOS), and refused older simulators and my own iPhone on iOS 26 with "None of the available devices are supported" | The message is quoted; why older runtimes are excluded I do not know |
| 4 | Approval was tied to the program that connects: Claude Code was approved, while a script of mine that started mcpbridge itself was refused with "agent isn't approved" until a workspace-opening tool call triggered an approval | Observed; I did not test other launchers |
That second row differs from Apple's third step, which says to open the project in Xcode first. I only tried it with the project path supplied, so follow Apple's step if it fails for you.
The loop I used
On a 27.0 simulator the loop was: start a workspace session, build and run the app through DeviceInteractionInstallAndRun, capture a screenshot and hierarchy, tap by coordinates read from the hierarchy file, then end the session. Ending the session did not shut the simulator down, so I shut it down myself with xcrun simctl shutdown.
The first boot of a fresh iOS 27 simulator pushed my Mac's load average to about 400 (as uptime reports it) for a while, with many shader compiler processes running. It happened once and I did not investigate why, so I note it only as a reason to run it on its own, not alongside another build.
What it does not replace
This was one app's worth of use on one machine. For a physical iPhone I use a different route, covered in The Agent Taps the Phone. Nothing Touches the Mac., because my iPhone was on iOS 26 and row 3 refused it. I have not tried the tools on a physical device running iOS 27 or later. If several agents share a Mac, builds and simulators are shared resources: see Running Multiple Claude Code Agents.
For where to put project hints for the agent, see what goes in CLAUDE.md.
What I did not measure
I did not compare Xcode MCP with calling xcodebuild directly, so I make no claim about which is better, faster or more reliable. I did not test Android Studio or any other mobile MCP server, and I have no data on how often a session hit an approval prompt. The 56-tool count and the 27.0 simulator rule are from one date and one Xcode build.
Related: Claude Code Hooks: Three I Run Every Day and Don't Trust an Agent That Says the Tests Passed.
Keep reading
- Gemini CLI vs Claude Code: What I Can and Cannot Say From My LogsA correction first: none of my logged runs used Gemini CLI. Here is what the Gemini rows are, what the two tools' docs say, and a dated tally with its limits.
- Using Codex as the Read-Only Reviewer for Claude CodeNot a benchmark: Claude Code writes and orchestrates, Codex reviews. The split, the verdict contract, and one case where the gate said no.
- CLAUDE.md File: What to Put In It and What to Leave OutWhat a CLAUDE.md file costs, what the docs say belongs in it, and the size history of mine: 3,639 words, then 512, then 9,555.