Xcode Index MCP

Why it's ranked here

A focused, credible choice for refactoring and navigation in Apple projects. It returns file locations and symbol roles from Xcode’s own index rather than relying only on text search. The narrow scope is useful, but setup requires both Python and Swift builds, a prepared Xcode index, and project-specific agent instructions.

What's good

The workflow connects name search, source-location lookup, unique symbol resolution, and reference discovery. Queries can distinguish definitions, declarations, reads, writes, calls, and other roles. Pattern matching supports anchored, subsequence, and case-insensitive searches. Swift tests exercise request dispatch, successful results, missing parameters, and unknown requests through a mock provider.

Tradeoffs

It only works with Xcode projects that already have index data in Derived Data. Users must install a Python package manager, synchronize dependencies, build the Swift service, configure an absolute executable path, and tell the agent the project name. Initial index scanning is explicitly costly and may block for up to 30 seconds.

How to use it well

Use it for iOS or macOS refactors where missing one call site would be costly. Start from a symbol name or an exact file and line, resolve its unique identifier, then collect definitions and references before editing. Keep text search nearby for locating source lines. It does not build missing Xcode indexes or perform code changes itself.

Observed

Languages

Python and Swift

Interface

MCP server with a packaged command-line entry point

Packaging

Python package built with Hatchling and synchronized with uv; Swift service built with Swift Package Manager

Platform

macOS 12 or later with Xcode installed and an Xcode-generated project index

Dependency surface

FastMCP, Requests, and Apple IndexStoreDB

Tests

Swift test target includes request-routing tests and mock index components