The headline most people took from Xcode 27 at WWDC was "Apple put AI in the IDE." The neural-engine code completion that runs on-device without sending your source anywhere is real, and it's a good feature. But it isn't the interesting one. The interesting one is a small binary called mcpbridge, and what it does is close to the opposite of "AI in the IDE." It takes the IDE and hands it to whatever AI you already use.

The inversion#

Think about how the Model Context Protocol normally runs. Your agent — Claude Code, say — is the host. It reaches out to MCP servers, the tools, over stdio or HTTP: a filesystem server, a database server, a browser-automation server. The IDE, in this picture, is either the thing the agent lives inside or the window where you type. It is a client of tools, never a tool itself.

mcpbridge flips that. It makes Xcode an MCP server — a tool that external agents call. External agents "that speak the Model Context Protocol — Claude Code, Cursor, OpenAI Codex — connect directly to Xcode's live process" and get "structured, real-time access to diagnostics, symbol information, SwiftUI previews, and the Swift REPL." You bring the model; Xcode brings the ground truth. Registering it is one line: claude mcp add --transport stdio xcode -- xcrun mcpbridge.

That reframing matters because it means Apple is not shipping a coding agent. It's shipping a tool for coding agents, and staying deliberately model-agnostic about which one you point at it.

The transport is the feature#

Here's the part that's easy to skate past and shouldn't be: mcpbridge speaks MCP over XPC — Apple's asynchronous, sandboxed inter-process communication framework — "rather than a network socket." That single choice is doing almost all the work.

There are already Xcode MCP servers. Sentry's XcodeBuildMCP and community projects like lapfelix/XcodeMCP wrap Xcode from the outside: they shell out to xcodebuild, poke the app over AppleScript, run its build, and then parse the xcresult and the log text back into something an agent can read. They work. But they are screen-scraping the compiler — reconstructing what happened from thousands of lines of unstructured output, after the fact.

Because mcpbridge lives inside the process, over XPC, it doesn't have to reconstruct anything. It has "direct access to Xcode's live state: active code diagnostics, resolved symbol information, SwiftUI preview rendering, and the Swift REPL." An agent invokes a capability with a structured JSON request and gets a structured JSON response — the compiler's own answer to "what symbol is this" or "what's the error on line 40," not a guess parsed out of a log.

An external server can start a build and read the wreckage. An in-process bridge can watch the compiler think.

That's why the transport is the whole story. XPC is what buys the fidelity. It's also what fences it in: an XPC connection is local and depends on Xcode's process being alive, so mcpbridge "requires a running Xcode instance" — close or crash the app and the tool calls fail — and it serves only the frontmost project. It cannot be a remote MCP server, because the thing that makes it trustworthy is precisely that it isn't on a socket. If you've been weighing MCP's stdio vs. SSE vs. streamable-HTTP transports, XPC is a fourth answer that only Apple can ship: no network, maximum context.

What it doesn't do — and why that's the tell#

mcpbridge exposes about 20 tools, and the honest boundary is that they cover build, test, preview, and diagnostics — not everything. Instruments profiling, Core Data model editing, and Interface Builder manipulation are "not exposed via MCP as of Xcode 27 beta 1." So the community servers don't die; they still reach the corners Apple hasn't wired up. This is a floor Apple laid, not a ceiling.

But look at which twenty capabilities got picked first, and the strategy is legible. Apple didn't expose the parts of Xcode a human clicks. It exposed the parts an agent needs to close a loop: make a change, build it, read the diagnostics, run the test, check the preview. mcpbridge is the expose-your-app-as-an-MCP-server pattern applied to the one app iOS developers can't leave — and the tools it chose to build first are exactly the compile-fix-verify cycle.

The strategic read is the one worth carrying out of this. Apple lost the frontier-model race — Siri now plans on Google's Gemini — so it is not going to win by shipping the best coding brain. Its play is to make its crown-jewel apps the best local tools on the device and let you rent whatever brain you like. Two weeks after WWDC it ran the same move again: Safari now gives agents a live browser window — 17 tools, no Apple cloud. The company famous for the walled garden is quietly turning its walls into MCP endpoints.

The bet underneath it is coherent: the model is a commodity you'll swap out twice a year; the live, high-fidelity, on-device context is not. Own the tools, rent the brain. mcpbridge is the first brick.