Skip to content
axint docs

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.

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:

Terminal window
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

  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.