Xcode

Axint does not replace Xcode’s own workspace/build/test tools. It sits alongside xcrun mcpbridge so your agent can generate Apple-native code, then use Xcode’s tools to write files, build, preview, and test.

Why this matters for WWDC26

Apple’s public developer docs now frame Xcode’s MCP bridge as the way external agents reach Xcode capabilities. That is good for Axint. It means the right architecture is not “Axint instead of Xcode.” The right architecture is two MCP servers in the same agent workflow:

• xcode-tools via xcrun mcpbridge for project files, builds, previews, tests, diagnostics, and Apple documentation search.
• axint via axint-mcp for App Intents generation, Swift validation, Cloud Check, Fix Packets, registry packages, and Apple-specific repair loops.

When Apple expands App Intents, Shortcuts, Apple Intelligence, or Foundation Models, Axint is the layer your agent calls before it guesses the Swift glue.

One-step setup

npx -y -p @axint/compiler axint xcode setup

This is the fastest way to configure the local agent side of the loop.

If you are using Xcode’s built-in Intelligence panel with Claude Agent, do not paste the raw MCP command into the agent chat. Xcode starts that agent with a restricted PATH, so the setup command writes a dedicated config with absolute Node and Axint MCP paths:

~/Library/Developer/Xcode/CodingAssistant/ClaudeAgentConfig/.claude.json

After setup, restart the Xcode agent session and ask:

What MCP servers are available?

You should see both xcode-tools and axint.

For a brand-new project or stale machine, the direct CLI command is:

axint xcode install --project .
axint doctor --dir .

Start every new Xcode agent chat this way

Use this as the first message in a new Xcode Intelligence or Claude Agent session:

Before editing Apple-native code, read the current Axint docs:
1. https://docs.axint.ai/guides/live-now/
2. https://docs.axint.ai/mcp/xcode/
3. https://docs.axint.ai/guides/xcode-happy-path/
4. https://docs.axint.ai/guides/cloud-check-loop/
5. https://docs.axint.ai/guides/fix-packets/
6. https://docs.axint.ai/reference/cli/

Then call axint.session.start and keep the returned sessionToken.
List MCP servers and confirm both xcode-tools and axint are available.
Call axint.status and report the running Axint MCP version.
Call axint.workflow.check with stage="context-recovery", the sessionToken from axint.session.start, readAgentInstructions=true, readDocsContext=true, and ranStatus=true.
Use Axint before guessing App Intents, widgets, SwiftUI scaffolds, entitlements, Info.plist keys, or repair prompts.
For existing SwiftUI repairs, preserve the current file and use the host editor's patch/write tools, then run axint validate-swift, axint cloud check, and a focused axint run --only-testing proof.
If the issue depends on nearby files, run axint project index --changed <files> before Cloud Check.
After each generated Apple surface or repair, run axint.workflow.check before claiming the work is done.

If the agent supports MCP prompts, request axint.project-start instead of pasting the full text.

Remote MCP for agent workflows

If you want the hosted HTTP endpoint instead of local stdio:

{
  "mcpServers": {
    "axint": {
      "url": "https://mcp.axint.ai/mcp"
    }
  }
}

Canonical remote endpoint: https://mcp.axint.ai/mcp

Recommended composition

1. Use Axint tools to scaffold or compile the Apple-native surface.
2. Use xcrun mcpbridge tools to write files into the Xcode project.
3. For existing-code repair, use the host editor’s patch tool first and let Axint validate/check the changed files.
4. Run axint project index --changed <files> when context outside the current file matters.
5. Build and preview inside Xcode to confirm the output behaves correctly.
6. Run axint run --only-testing <UITestTarget/Class/testName> for focused proof before calling the fix complete.

Also useful

• The SPM build plugin remains the right option when you want compile-time generation on every build.
• Xcode happy path → is the shortest install → build → check → packet → rerun walkthrough.
• Cloud feedback loop → explains how failed checks become test-backed Axint improvements.
• Fix Packets → explains the repair contract that the plugin and Xcode helpers both read.
• axint-examples gives you starter repos that are easier to test in Xcode than isolated snippets.