apple-doc-mcp makes an AI assistant choose a framework before it searches Apple's docs

An MCP server for Apple's developer documentation

apple-doc-mcp is a Model Context Protocol server that gives an AI coding assistant access to Apple's Developer Documentation. The package on npm is called apple-doc-mcp-server, the binary is apple-doc-mcp-server, and it is written in TypeScript.

The dependencies explain the design. There are exactly two runtime dependencies, the Model Context Protocol SDK and axios. The MCP SDK is the transport and protocol layer, and axios is the HTTP client used to talk to the documentation service. There is no database, no vector store, no embedding model and no local corpus in the dependency list.

That last point is the most important thing to understand about how this works. The tool is a search client, not a copy of the documentation. The README describes it as providing access to Apple's Developer Documentation directly within your AI coding assistant, and the tool list confirms the shape: discover_technologies, choose_technology, current_technology, search_symbols, get_documentation and get_version. Every one of those is a query against a remote source rather than a lookup into a bundled index.

The repository topics are apple, ios, swift and xcode, so the audience is developers working in that stack who already use an MCP capable assistant.

You pick a framework before you are allowed to search

The tool list encodes a two step workflow that is easy to miss and changes how the assistant behaves.

discover_technologies browses and filters the available frameworks before one is selected. choose_technology then sets the active framework, and the README marks it as required before searching docs. current_technology shows the current selection along with quick next steps, which suggests the server keeps that state in the session.

This design has a clear rationale. Apple documentation is organised around frameworks such as SwiftUI and UIKit, and the same symbol name can mean different things in each. Forcing a framework choice before the search is a way of removing ambiguity before a query is even issued, and it is why the search tips tell you to re-run discover_technologies with a different keyword or pick another framework when nothing turns up.

The downside is equally clear. A conversation that spans two frameworks, or a question about a system framework that is not in the list, forces extra tool calls before any documentation comes back. The state also has to be managed by the caller, since the selection is set once and then used by later searches.

search_symbols was rewritten to be predictable for agents

The changelog in the README is the most informative document in the repository, and version 1.9.6 is where the work is.

The entry calls it a major fix that simplified search_symbols to be more predictable for AI agents. It added exact symbol resolution inside search_symbols for queries such as GridItem, View and ButtonStyle, and changed search_symbols to return symbol-first results with articles and guides separated into their own section. The search tips in the README state the same thing in one line: search_symbols returns symbols first and lists matching articles separately.

The other fix in that version is about wildcards. The changelog says wildcard behaviour was fixed so that fallback search respects * and ? patterns instead of degrading to plain substring matches. That is a meaningful change: a query like Grid* or *Item or Lazy* now means what it looks like it means.

Two more entries are about honesty and hygiene. The changelog says misleading search messaging about background downloads and comprehensive indexing was removed, and that dead or unused search code paths were removed. There is also a fix for first-search index initialization, so that a cache-backed symbol search finishes building before its results are used.

That last one is the kind of bug that produces confidently wrong answers, so it is worth knowing about if you have used an earlier build.

Search tips, and the order you should try queries in

The README has a short list of search tips, and read as a workflow it tells you how to get the most out of the server.

Use exact API names when you know them, with GridItem, View and ButtonStyle given as the examples. Start broad with a term like tab, animation or gesture. Try synonyms, the README pairing sheet against modal and toolbar against tabbar. Use wildcards such as Grid*, *Item and Lazy* for flexible matching. Use multiple keywords, like tab view layout, to narrow results. If nothing turns up, re-run discover_technologies with a different keyword or pick another framework.

The order in that list is a sensible escalation path from precise to fuzzy, and it is the opposite of how people usually search. The exact name path is the fastest because exact symbol resolution is what the server was recently improved to do.

One piece of guidance for the people configuring an assistant rather than using it: the server is aware of wildcards, but the model has to send them. If your assistant paraphrases a query before sending it, the wildcard support never gets used, and you land in the fallback path that the changelog had to fix.

Adding the server to VS Code, Claude Code and Codex

There are four documented installation routes, and they differ in how much you trust the client to fetch the package.

In VS Code you open the Command Palette, run MCP: Add Server, choose npm when asked for the server type, and enter the package name.

apple-doc-mcp-server

Claude Code and Codex both take a single command.

claude mcp add apple-docs -- npx apple-doc-mcp-server@latest

codex mcp add apple-doc-mcp -- npx apple-doc-mcp-server@latest

Or you can write the server entry yourself, which is the route to use if you want to pin a version instead of tracking latest.

{
	"mcpServers": {
		"apple-docs": {
			"command": "npx",
			"args": ["apple-doc-mcp-server@latest"]
		}
	}
}

The local route builds from a checkout with yarn install and yarn build, then points the client at the built file with node and an absolute path.

yarn install
yarn build

The build script in package.json is tsc followed by making dist/index.js executable, and the start script runs node dist/index.js, so the entry point the clients invoke is a plain Node script.

Logging to stderr, because stdout carries the protocol

One changelog entry deserves its own paragraph, because it is the kind of bug that looks like a client problem.

Version 1.9.1 moved cached docs into a .cache/ directory to keep the repository clean, and routed MCP logging to stderr so that protocol stdout stays clean. The changelog is explicit that this was breaking codex symbol search.

The reasoning is sound. An MCP server speaks its protocol over standard output, so a stray log line on stdout corrupts the stream the client is parsing. The symptom would be a client that appears to start and then fails to list tools, or a tool call that never returns, with the error pointing at the client rather than at the server. The same version that fixed the search behaviour had to fix the transport, which is a reminder that for an MCP server the output streams are part of the contract.

The .cache/ move is the other half of that release, and it is a small design decision with a real consequence. Cached documentation lands inside the project directory, which is convenient for a local checkout but means the server is writing to your working tree. The repository lists a .gitignore at the top level, so the cache is expected to be ignored by version control, but it is still a write into a directory that some workflows keep read only.

Six tools, a small API surface and a maintainer asking for sponsorship

The tool list is the whole API: discover_technologies to browse and filter frameworks, choose_technology to set the active one, current_technology to show the selection and next steps, search_symbols for symbol first search with exact name resolution and wildcards, get_documentation to open detailed docs for a known symbol or documentation path, and get_version for version information.

Six tools is a small surface, which matters for an MCP server because every tool is exposed to the model and a larger catalogue increases the chance of a wrong tool being picked. The get_documentation tool takes a known symbol or a documentation path, so the intended flow is search then fetch, not fetch first.

The README asks for sponsorship directly and explains why: the author says working on it regularly is getting expensive to build and improve across platforms while adding features, and points to a sponsor button, thanking individual sponsors by name along with the GitHub team.

That context tells you how to evaluate the project. It is a solo maintained project with a published changelog, an npm package, MIT licensing and a lint, typecheck and format setup in package.json, but no team behind it and no GitHub releases, so version pinning is done through the npm tag rather than a release list.

On maintenance, the repository is not archived and the last push was on 2026-05-13, and the package version in package.json is 1.9.6, which matches the newest changelog entry.

Editorial conclusion

Adopt apple-doc-mcp if you write Swift, SwiftUI or UIKit code with an AI assistant and want the model to consult Apple's own documentation rather than recall it. Do not adopt it expecting parity with Apple's documentation set, since the tool indexes a subset organised around frameworks, and treat the framework selection step as mandatory rather than optional. Before you wire it in, read the CHANGELOG for the version you install, confirm the server starts with clean protocol output on stdout, and check the search tips so your first queries use exact symbol names instead of prose.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. MightyDillah/apple-doc-mcp on GitHub
4. README