apple-docs-mcp: Apple Developer Documentation Inside Claude, Cursor and Other MCP Clients
MCP server for Apple Developer Documentation - Search iOS/macOS/SwiftUI/UIKit docs, WWDC videos, Swift/Objective-C APIs & code examples in Claude, Cursor & AI assistants
At a glance
- What is it?
- A TypeScript MCP server that exposes Apple's developer documentation, WWDC session library and sample code to AI assistants over stdio. It is a documentation retrieval layer, not an offline index, and that distinction decides whether it fits your workflow.
- Who is it for?
- Adopt apple-docs-mcp if you already work inside an MCP client and want Apple framework references, WWDC session material and sample code pulled into the same conversation where you write Swift or Objective-C. Skip it if you need deterministic, offline or version-pinned documentation, because the README describes a server that queries Apple's documentation endpoints at request time and rotates UserAgents to do so.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Activity is slowing. The repository last received commits 6 months ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap apple-docs-mcp fills between an AI assistant and Apple's own documentation
An assistant writing Swift knows the shape of SwiftUI and UIKit from training data, but training data has a cutoff. Ask about an API introduced in a recent SDK and the model either guesses or refuses. The usual workaround is pasting documentation into the chat window by hand, which is slow and easy to get wrong.
This project takes a different route. It registers as a Model Context Protocol server, so the assistant can call it as a tool during a conversation. The README lists the surfaces it exposes: search across Apple Developer Documentation for SwiftUI, UIKit, Foundation, CoreData and ARKit; a framework index for browsing hierarchical API structures on iOS, macOS, watchOS, tvOS and visionOS; a technology catalog covering SwiftUI, UIKit, Metal, Core ML, Vision and ARKit; documentation updates tracking WWDC 2024 and 2025 announcements plus iOS 26 and macOS 26; technology overviews; a sample code library with Swift and Objective-C examples; a WWDC video library spanning 2014 to 2025 with transcripts and code examples; related API discovery; and platform compatibility analysis for iOS 13+, macOS 10.15+, watchOS 6+, tvOS 13+ and visionOS.
The audience is narrow but real: developers who already use an MCP-capable client for Apple platform work. If you write Kotlin or Rust, nothing here applies. If you write Swift but never use an AI assistant with tool calling, the server has no consumer.
How the server works: a stdio MCP process that queries Apple's documentation endpoints
Every installation example in the README uses the same shape: a stdio server launched by the client. Claude Desktop, Cursor, VS Code, Windsurf, Zed, Cline and the Amazon Q Developer CLI all get a command plus arguments, and the client spawns that process and speaks MCP over standard input and output. There is no daemon to keep alive and no port to open.
The README describes the data path in general terms. The server accesses Apple's JSON API for Swift, Objective-C and framework documentation, and it runs what the README calls a Smart UserAgent Pool: a rotation system with automatic failure recovery and performance monitoring. That detail is the most informative line in the feature list. It tells you the server is making outbound HTTP requests to Apple-hosted endpoints, that those requests can fail, and that the author built retry and identity-rotation machinery because they do fail. Nothing in the README documents a bundled local corpus or a cache directory, so treat documentation lookups as network-bound operations against a third party you do not control.
The tool set is organized by intent rather than by URL. Search, framework index browsing, technology catalog, updates, overviews, sample code, WWDC videos, related APIs and platform compatibility are separate capabilities, which means the assistant chooses among them. The README's usage examples show the intended phrasing: "Search for SwiftUI animations", "Get platform compatibility for SwiftData", "Show me UITableView delegate methods". Those are natural language prompts, not structured queries, so result quality depends on how the server translates them into Apple's own API calls.
Installing it: one npx command, several client-specific config files
The fastest path is Claude Code, where the README gives a single command:
claude mcp add apple-docs -- npx -y @kimsungwhee/apple-docs-mcp@latest
For Claude Desktop, edit claude_desktop_config.json, 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 mcpServers entry whose command is npx and whose args are ["-y", "@kimsungwhee/apple-docs-mcp"]. The README flags a real failure mode here: if an old version keeps getting used, append @latest to the package specifier. That is a version-pinning problem, not a documentation problem, and it will bite anyone who installed early and later wondered why new tools were missing.
Cursor reads ~/.cursor/mcp.json with the same mcpServers block. VS Code uses a config with a "mcp" key containing "servers", and each entry needs "type": "stdio" alongside command and args. Zed puts the server under "context_servers" with a nested command object holding path and args. Cline adds "disabled": false and "autoApprove": [] to the standard block and can also be installed from its marketplace. On Windows the README swaps the command to cmd with args ["/c", "npx", "-y", "@kimsungwhee/apple-docs-mcp"], which is the standard workaround for npx resolution on that platform.
Global installation is available through pnpm add -g @kimsungwhee/apple-docs-mcp or npm install -g @kimsungwhee/apple-docs-mcp, and npx @kimsungwhee/apple-docs-mcp --help prints usage without a client. Building from source is git clone, cd apple-docs-mcp, then pnpm install && pnpm run build (pnpm is marked recommended) or npm install && npm run build.
The dependency you inherit: Apple's endpoints and an undocumented UserAgent pool
The Smart UserAgent Pool is the clearest limitation in the material. A rotation system with failure recovery exists because requests to Apple's documentation endpoints get rejected or throttled. The README does not state the pool size, the rotation interval, the backoff policy, or what the server returns to the assistant when every attempt fails. That last question matters most: an assistant that receives an empty result may answer from training data instead, and you will not necessarily see the difference in the transcript.
Second, there is no documented offline mode, local index or cache. Every lookup depends on network reachability and on Apple's endpoints continuing to respond in the shape the server expects. Apple has changed documentation URLs and JSON structures before, and a client-side scraper has to follow. The README's changelog surface (WWDC 2024 and 2025, iOS 26, macOS 26) suggests active tracking, but tracking is maintenance work, not a guarantee.
Third, the fit is wrong for some teams. If your build pipeline needs reproducible documentation snapshots, or your environment has no outbound internet, this server is the wrong tool. If you need to answer questions about a private framework or an internal SDK, it has nothing to say. And if your assistant already has web access, adding a documentation-specific MCP server buys you structured tool calls, not new information.
How this differs from pointing an assistant at the documentation website
The obvious alternative is giving the assistant a browser tool or a general web fetch and letting it read developer.apple.com directly. The difference is in what comes back. A raw page fetch returns HTML or a large JSON blob that the model must parse, and the model has to guess which URL holds the answer. apple-docs-mcp instead exposes named capabilities: search, framework index, technology catalog, updates, overviews, sample code, WWDC videos, related APIs, platform compatibility. The assistant picks a capability and the server handles URL construction and response shaping.
That is the whole trade. You gain structured retrieval and lose transparency, because you no longer see which URL produced an answer. You also take on a dependency that a plain web fetch does not have: the server's parsing logic has to keep pace with Apple's response format. A browser-based approach degrades more gracefully when Apple changes something, because the model reads whatever is there. A dedicated MCP server either parses correctly or returns nothing useful.
For WWDC material specifically, the README describes a video library covering 2014 to 2025 with transcripts, Swift and SwiftUI code examples, and resources. General web search can find session pages, but transcript-level retrieval through a tool call is a different workflow, and that is where this project's value concentrates.
Maintenance, versioning and what the MIT licence does and does not cover
The package is published to npm as @kimsungwhee/apple-docs-mcp, and the most recent release listed is v1.0.26 from 2025-09-15, with repository activity recorded into March 2026. Version numbers in the 1.0.x range with frequent point releases are typical of a project that ships small fixes, often in response to upstream changes. Budget for occasional upgrades rather than a stable frozen dependency.
Upgrade cost is close to zero in the common case, because most clients run the package through npx and pick up whatever the registry serves. That convenience is also the risk: without a pinned version, a client can silently move to a new release. The README's own note about adding @latest to escape a stale cached version shows the flip side of the same mechanism. If you need reproducibility, pin an explicit version in the args array instead of relying on the default resolution.
The MIT licence covers the server code. It does not cover Apple's documentation, WWDC transcripts or sample code, which remain Apple's material under Apple's terms. Running an MCP server that fetches those pages is a different question from redistributing them, and this article is not legal advice. If your organisation has rules about automated access to third-party documentation sites, check them before deploying the server broadly.
Who should run this server, and what to check before you do
Install it if you write Swift, SwiftUI, UIKit or Objective-C and you already work inside Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, Zed, Cline or the Amazon Q Developer CLI. The setup is a JSON block or a single command, and the payoff is that questions about framework APIs and WWDC sessions get answered from Apple's own material rather than from a model's memory of it.
Do not install it if your environment blocks outbound requests, if you need version-pinned documentation that matches a specific SDK in your build, or if you want answers about code that is not public Apple material. The server has no offline mode described in the README, and the UserAgent rotation exists precisely because the upstream endpoints push back.
Before trusting it in daily work, run npx @kimsungwhee/apple-docs-mcp --help to confirm the binary resolves, then restart your client and check that the tool list appears. Ask one question whose answer you can verify against developer.apple.com, such as a platform availability figure for a specific API, and compare. If the server returns nothing on a query you know has an answer, that is the failure mode to watch for, and it points at the UserAgent pool or at an upstream response change rather than at your configuration.
Editorial conclusion
Adopt apple-docs-mcp if you already work inside an MCP client and want Apple framework references, WWDC session material and sample code pulled into the same conversation where you write Swift or Objective-C. Skip it if you need deterministic, offline or version-pinned documentation, because the README describes a server that queries Apple's documentation endpoints at request time and rotates UserAgents to do so. Before rolling it out, verify three things on your own machine: that npx resolves the version you expect, that the client actually lists the tools after a restart, and what the server does when Apple's endpoints rate-limit or change shape.
Community notes