What makes this safe to hand to an agent is the base path — every project and file path resolves relative to it and anything outside is rejected, which matters when the tools can create, move and delete targets. The build-phase and app-extension tools save the most clicking: both are multi-step in the Xcode interface and a single call here. Because it runs in a container, what it can reach is exactly what you mounted.
A Swift server that edits Xcode project files directly. It can create a project from nothing, then manage the targets, files, groups, build settings, frameworks and Swift Package dependencies inside it.
- A new project created with organisation name and bundle identifier set
- The project read back: targets, build configurations, the files in a target, and the group hierarchy
- Files added to a target, removed, moved or renamed, and groups created in the navigator
- A folder reference that stays in sync with the file system, for asset and resource directories
- Targets created, removed, duplicated, and made to depend on each other
- App extensions created and embedded in a host app — widget, share, notification, keyboard, intents and more — and removed again
- Build settings read and written per configuration, frameworks linked or embedded, and custom build phases added for formatters and linters
- Swift Package dependencies added, listed and removed
- A base directory given at startup that every path resolves against — anything outside it is refused
macOS and a container runtime, since the server ships as a linux/arm64 image rather than a binary: Apple's own container tool on Apple silicon running macOS 26 or later, or Docker on anything earlier. Either way the project directory is mounted at /workspace and passed as the base path, which is also the boundary the server refuses to write outside. MIT.
One command — docker run --rm -i -v ${workspaceFolder}:/workspace ghcr.io/giginet/xcodeproj-mcp-server /workspace