Provides offline search of Apple Developer Documentation from Xcode's local documentation index, returning full text, code examples, availability, and scores, along with framework listing and documentation status tools.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@apple-docs-mcp search SwiftData model inheritance"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server and CLI that search Apple Developer Documentation from Xcode's on-disk documentation index — fully offline, no network calls.
Coding agents recall Apple APIs from training data that lags the installed SDK. This server gives them the real text: signatures, availability, and code examples, straight from the documentation that Xcode already downloaded.
Xcode installs a local copy of the Apple Developer Documentation asset. It looks like a source an agent could read directly, but the prose is not readable in place:
index/index.json (104 MB) holds navigation nodes — path, title, type —
and no prose. The keys abstract, declarationFragments, and
primaryContentSections appear zero times.
cache.db stores 1269 compressed blobs whose header (9b21f31f) decodes under
none of LZ4, LZFSE, zlib, LZMA, or LZBITMAP via Apple's libcompression.
documentation-db/index.sql (1.2 GB) is a vector store for Xcode's own
semantic search, not text.
Xcode 27 exposes an MCP service with a DocumentationSearch tool that answers
from this asset. Measured behavior: 19–20 documents per query with full
contents and code examples, ~0.4 s median latency, and zero bytes of network
traffic. This project wraps that tool so any MCP client can use it, and adds an
offline framework index that needs no approval at all.
Related MCP server: Apple Deep Docs MCP
Requires macOS, Xcode installed, and uv.
git clone https://github.com/Ahmetshbzz/apple-docs-mcp
cd apple-docs-mcp
uv syncInstall the CLI on your PATH:
uv tool install --editable .Claude Code:
claude mcp add apple-docs --scope user -- \
uv run --quiet --project /path/to/apple-docs-mcp apple-docs-mcpCodex (~/.codex/config.toml):
[mcp_servers.apple-docs]
command = "uv"
args = ["run", "--quiet", "--project", "/path/to/apple-docs-mcp", "apple-docs-mcp"]
startup_timeout_sec = 60Tool | Purpose |
| Search documentation by meaning; returns full text, code examples, |
| List every framework in the local index (~395). Offline, no approval needed |
| Report whether search is usable right now, and why not if it is not |
apple-docs search "SwiftData model inheritance" --framework SwiftData
apple-docs search "AVAudioSession category" --json
apple-docs frameworks
apple-docs statusExit codes are distinct per failure so scripts can branch:
0 success, 1 usage, 2 not approved, 3 Xcode unavailable, 4 timeout,
5 protocol, 6 asset missing.
This is the one thing to understand before using it.
search_docs drives mcpbridge, so Xcode must be running with an approved
workspace:
xcrun mcp-server open <path-to-project> # accept the dialog in XcodeApproval is granted per process, not per user. A different interpreter needs its own approval.
Approval expires after 24 hours.
Approval requires an open workspace; the documentation search itself is global, so any project works.
Every failure returns a typed error with a remedy. The tool never returns an empty list to signal a problem, because an empty result is indistinguishable from "this API does not exist" — the exact confusion it exists to prevent.
list_frameworks reads index.json directly and needs none of this.
uv run pytest tests/ # 37 tests
uv run pytest tests/ -m integration # live bridge tests
uv run ruff check src testsUnit tests need no Xcode. Integration tests skip themselves when the bridge is absent or unapproved.
One implementation, two interfaces. Business logic is not duplicated.
src/apple_docs_mcp/
├── bridge.py # mcpbridge JSON-RPC client; owns the protocol and typed errors
├── frameworks.py # offline index.json reader
├── responses.py # shared JSON payload contract
├── cli.py # argparse adapter
└── server.py # MCP adapterMeasured 2026-09-17, not assumed:
Thing | Value |
Xcode | 27.0 (27A266a) |
Swift | 6.4 (swiftlang-6.4.0.34.1) |
Simulator runtime | iOS 27.0 (24A434) |
Documentation asset | Build 10M13950, ~1.6 GB, ~395 frameworks |
MIT — see LICENSE.
Report whether documentation search is usable right now: asset presence, bridge path, and whether this process is approved to use Xcode's tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It does so well by framing the tool as a pure report and listing the three checks it performs, which implicitly signals a non-mutating status operation. It could be more explicit about having no side effects, but 'Report whether' plus the enumerated checks provides strong transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence followed by a compact colon-separated list. Every phrase earns its place, and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status tool with an output schema available, the description covers what the tool reports, when it is relevant, and which aspects are checked. It could have explicitly instructed the agent to call it before search_docs, but nothing essential for invoking it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There is no parameter information needed in the description, and the description does not attempt to add any because none is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Report') and a specific subject ('whether documentation search is usable right now'), then enumerates the scope: asset presence, bridge path, and Xcode approval. This clearly distinguishes it from sibling tools like search_docs and list_frameworks, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'usable right now' makes it clear this is a readiness/precondition check, so an agent understands to call it when it needs to verify documentation search is available before searching. It does not explicitly name alternatives or exclusion conditions, but the intended timing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every framework in Xcode's local documentation index. Runs offline and needs no Xcode approval.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It meaningfully discloses that the tool runs offline and needs no Xcode approval, which addresses common permission and environment concerns. It does not describe ordering or other return details, but the output schema exists to cover return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler; the first states the core purpose and the second adds two key behavioral constraints. Everything present earns its place, and the description is immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list operation with an output schema, the description is complete: it names the resource, clarifies it covers every framework, and adds offline/no-approval context. An agent has everything it needs to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing for the description to explain about parameter usage. With 100% schema coverage of an empty schema, the baseline of 4 is appropriate, and no further parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a precise resource ('every framework in Xcode's local documentation index'), making the tool's scope unmistakable. It clearly differentiates this from siblings like search_docs and doc_status by stating it enumerates all frameworks rather than searching or checking status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when this tool is appropriate: when a complete framework list is needed, and it works offline without requiring Xcode approval. It does not explicitly name alternatives or exclusion conditions, but the usage context is clear enough for an agent to select it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Apple Developer Documentation by meaning, using Xcode's local documentation index. Returns full document text including code examples, with each result's uri and match score. Use this before answering from memory about Swift or Apple platform APIs.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural-language or API search query. | |
| timeout | No | Seconds to wait for the bridge before failing. | |
| frameworks | No | Restrict the search to these frameworks, e.g. ['SwiftData']. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the search is semantic ('by meaning'), uses a local Xcode index, and returns full document text with code examples, uri, and match score. It does not mention failure modes or side effects, but this is a read-only search operation and the core behavior is well conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no filler. The first sentence states the core purpose, the second describes the return value, and the third gives actionable usage guidance. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage context, return contents, and the underlying local-index mechanism. An output schema exists to document the exact return shape, and the schema documents all parameters. It could add a note about prerequisites or when to use list_frameworks first, but it is otherwise complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds context about the search approach and return format but does not add meaning to the parameters themselves beyond what the schema already provides for query, timeout, and frameworks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Search Apple Developer Documentation by meaning, using Xcode's local documentation index.' It also explains what is returned (full document text, code examples, uri, match score), making the tool's function unmistakable and distinct from the sibling tools list_frameworks and doc_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Use this before answering from memory about Swift or Apple platform APIs.' It does not explicitly mention when not to use it or alternatives, but the sibling tools are clearly different in purpose, so no exclusion is necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0doc_statuslist_frameworkssearch_docsScored across 3 tools
Each tool has a clearly distinct role: search_docs finds documentation, list_frameworks enumerates available documentation domains, and doc_status reports tooling health. There is no meaningful overlap or ambiguity between them.
search_docs and list_frameworks follow a clear verb_noun snake_case pattern, while doc_status is a noun_noun name rather than a verb-based one. The naming is still consistent in style and readable, but the health-check tool deviates slightly from the verb-led convention.
Three tools is well-scoped for a documentation lookup server: one core search action, one discovery action, and one operational status check. Each tool clearly earns its place without redundancy or bloat.
The server covers the main documentation workflow well: searching docs, listing available frameworks, and verifying tool readiness. A direct fetch-by-URI option is missing, but since search_docs returns full document text, it is not a serious dead end.
Apple Developer Documentation with Semantic Search, RAG, and AI reranking for MCP clients
Get up-to-date, version-specific documentation and code examples from official sources directly in…
Search and read Rust documentation for the standard library and any crate on crates.io
Search public open-source code, documentation, metadata, vulnerabilities, changelogs, and examples.
