apple-docs-mcp: Apple Developer Documentation inside Claude, Cursor and VS Code

The gap apple-docs-mcp fills between an AI assistant and Apple's documentation

Ask a general-purpose model about a SwiftUI modifier and you get an answer shaped by training data with an unknown cutoff. Ask it about an API that shipped in a recent SDK and the answer may be a confident fabrication. Apple publishes the underlying material as structured JSON, but that JSON is not something you want to fetch and parse by hand while writing a view.

This project is a Model Context Protocol server that sits between an MCP-compatible assistant and Apple's developer documentation. The README frames the audience directly: iOS, macOS, watchOS, tvOS and visionOS developers working in Claude, Cursor, or any MCP-compatible client. The value proposition is not that it summarizes documentation. It is that the assistant can call a tool, get Apple's own text and code samples back, and answer from that instead of from memory.

The scope is wider than API reference. The feature list covers framework indexes, a technology catalog, documentation updates around WWDC 2024 and 2025 and iOS 26, sample code in Swift and Objective-C, WWDC sessions from 2014 to 2025 with transcripts, related-API discovery, and platform compatibility analysis down to iOS 13, macOS 10.15, watchOS 6 and tvOS 13. That breadth is the reason to consider it over a single-purpose search script, and also the reason to check which tools your client actually exposes.

How the server talks to Apple: JSON endpoints, a UserAgent pool, and a local data directory

The architecture is a stdio MCP server written in TypeScript, published as an ES module, with its entry point at dist/index.js and a bin alias of apple-docs-mcp. The build script is the telling detail: tsc compiles the sources and then copies the data directory into dist. That means part of what the server knows ships inside the package rather than being fetched at runtime, which is why the published tarball includes dist and the README files but not src.

On the network side, the README describes access to Apple's JSON API for Swift, Objective-C and framework documentation, plus a smart UserAgent pool with rotation, automatic failure recovery and performance monitoring. Read that as an admission: the upstream endpoints are not a documented, versioned public contract with a stability guarantee, so the server hedges by cycling request identities and retrying. It is a pragmatic design, and it also means behavior can change without a version bump on this side.

One consequence worth stating plainly: because the server depends on live upstream requests, it is not an offline documentation cache. The only bundled material is whatever sits in data/, and the README does not enumerate its contents or describe a fallback path when the network call fails. If your build environment is air-gapped, this design is the wrong shape for the problem.

Installing apple-docs-mcp and running a first query in Claude Desktop

The README's recommended path is Claude Desktop. Open the client configuration file, which lives at ~/Library/Application Support/Claude/claude_desktop_config.json on macOS and %APPDATA%\Claude\claude_desktop_config.json on Windows, and add an entry under mcpServers. The command is npx with the -y flag so no install prompt blocks startup.

{
  "mcpServers": {
    "apple-docs": {
      "command": "npx",
      "args": ["-y", "@kimsungwhee/apple-docs-mcp"]
    }
  }
}

Restart Claude Desktop after saving. The README notes that if an old version keeps getting picked up you can pin the latest explicitly by changing the args to ["-y", "@kimsungwhee/apple-docs-mcp@latest"]. That note is worth taking seriously rather than skimming: npx caching is the most common reason a freshly added server behaves like a stale one.

For Claude Code the README gives a one-liner instead of a config file:

claude mcp add apple-docs -- npx -y @kimsungwhee/apple-docs-mcp@latest

Cursor takes the same JSON shape in ~/.cursor/mcp.json, VS Code uses an mcp.servers block with a "type": "stdio" field, and Zed uses a context_servers block whose command is an object with path and args. Windows users get a separate variant that wraps the call in cmd /c. Once the client restarts, ask something concrete, for example "Search for SwiftUI animations" or "Find withAnimation API documentation". What you should see is the assistant invoking an Apple docs tool and returning text that reads like Apple's own reference pages, not a paraphrase.

Where apple-docs-mcp breaks down, and who should not install it

The first limitation is upstream dependency. Every search, framework lookup and WWDC transcript retrieval is a request against Apple's servers. The README documents a UserAgent rotation system specifically to cope with failures, which tells you the maintainers expect throttling or rejection to happen. If Apple changes response shapes, the server's parsing can break before any local test catches it, and the README does not describe a versioned compatibility layer.

The second is verification. There is no documented way to confirm that a returned snippet is current for your target SDK. The feature list mentions beta and status tracking for iOS 26 beta APIs and deprecated UIKit methods, but the README does not explain how deprecation status is surfaced in a tool response, so treat any such claim as something to check against Apple's site before you act on it.

The third is fit. If you want documentation available on a plane, in a locked-down CI container, or behind a proxy that blocks arbitrary outbound hosts, this server will not help you. If your questions are mostly about your own codebase rather than Apple's frameworks, a documentation server adds a tool call and a round trip for nothing. And if you are already satisfied with an assistant that answers framework questions well from training data, the marginal gain is smaller than the README's feature list implies.

How apple-docs-mcp differs from Sosumi MCP and generic web-fetch tools

Sosumi MCP is the closest alternative, and it appears in the related searches alongside this project. Both expose Apple developer documentation to an MCP client, so the difference is not the destination but the emphasis. Sosumi's approach centers on retrieving Apple documentation pages as structured content for the assistant to read. apple-docs-mcp adds layers on top of that idea: a framework index for browsing hierarchical API structures, a technology catalog, related-API discovery, and a WWDC library spanning 2014 to 2025 with transcripts and code examples.

The practical difference shows up in what you ask. For "show me the documentation page for UIViewController", either approach can work. For "what SwiftUI views are related to this API" or "find the WWDC session where this was introduced", the extra tooling in apple-docs-mcp is the reason to pick it. The trade-off is surface area: more tools means more for the model to choose between, and a wider dependency on upstream endpoints that can each fail independently.

A generic web-fetch MCP server is the other comparison. It can retrieve the same pages, but it returns raw HTML for the model to interpret, with no framework index and no notion of related APIs. If you want one tool that also reads your issue tracker and your wiki, a fetch server is more general. If you want Apple-specific structure, this project is the narrower and better-targeted choice.

Maintenance, upgrades and what the MIT license does and does not cover

The repository is not archived. Its last push was on 2026-03-17, which is more than six months before today, so the honest description is that the project has not seen a push in roughly half a year rather than that it is under active development. The most recent release noted is v1.0.26 from 2025-09-15, and package.json carries the same version. A quiet period is not abandonment, but it does mean that if Apple changes an endpoint tomorrow, the fix depends on the maintainer returning to the project.

Upgrade cost is low by design. The README's install path is npx against the published package, so upgrading is a matter of resolving a newer version, or pinning @latest to force it. There is no server process to keep running, no port to open, no database to migrate. The one operational wrinkle is npx caching, which the README addresses directly with the @latest suffix. For teams, pinning an explicit version in the client config is the more predictable option, at the cost of manual bumps.

The license is MIT. That permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are retained. It offers no warranty, and it says nothing about the terms that apply to Apple's documentation content itself, which the server merely retrieves. If you plan to redistribute retrieved Apple material, that question is separate from this project's license and belongs with whoever handles your legal review.

Editorial conclusion

Adopt apple-docs-mcp if you already drive Claude Code, Cursor, VS Code or Zed and want Apple API answers grounded in Apple's own JSON rather than the model's training data. Skip it if you need offline documentation, if you work in an environment that cannot run npx, or if you need the server to guarantee a result for every query. Before rolling it out, verify three things yourself: that the pinned version in package.json is the one your client actually resolves, that your network path to Apple's documentation host is not blocked, and that the tool names your assistant reports after restart match the ones you expect.

Frequently asked questions

Official sources

1. kimsungwhee/apple-docs-mcp on GitHub
2. License: MIT
3. Project website
4. README
5. Releases