Building from a command line is well covered elsewhere. Reading an .xcresult bundle - console output around the failure, a screenshot at the exact timestamp, the UI hierarchy compressed enough to fit in a reply - is what turns a red test into something a model can actually diagnose. Note the direction of travel: the author expects to default to sidekick mode alongside Apple's own server.
A server that controls the Xcode application through JavaScript for Automation rather than shelling out to xcodebuild, so builds and runs happen inside the IDE you already have open. It also parses build logs and digs into .xcresult bundles.
- Projects and workspaces: open one, read workspace status, list projects, and open a file at a line
- Build, clean, test, build-and-run, debug and stop, with build errors parsed to precise file and line
- Schemes listed and switched, and run destinations - simulators and devices - enumerated
- Test results browsed from an .xcresult bundle, with a quick summary and per-test console output
- Screenshots extracted from failing tests at a timestamp you choose
- UI hierarchies returned as compact JSON, with a follow-up call for the full properties of one element by index
- Attachments listed and exported, and an environment health check that reports what is missing
macOS with Xcode installed, and Node.js 18+; run it with npx and the published package. XCLogParser is recommended and installed with Homebrew - without it the server still works but build error parsing is limited. Preferred scheme and project can be set in the environment so tool parameters become optional on a single-project workflow. Apple now ships an official Xcode MCP server; this one can run beside it in sidekick mode, which restricts it to project management and test-result analysis.
One command — npx -y xcodemcp@latest