Search through Apple's complete developer documentation, including API references, code examples, WWDC session transcripts, and Human Interface Guidelines across all Apple platforms.
Click on "Install 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-server Show me SwiftUI animation code examples"
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.
Search through Apple's complete developer documentation using your AI coding assistant.
This tool connects your AI assistant (like Cursor) to Apple's entire developer documentation. Instead of manually browsing developer.apple.com, your AI can search through Apple's docs and provide precise answers with source links.
Complete documentation coverage:
All Apple platforms: iOS, macOS, watchOS, tvOS, and visionOS - from early versions to current iOS 26, macOS 26, watchOS 26, tvOS 26, visionOS 26
WWDC session transcripts from 2019-2025 (including latest WWDC 2025 with Liquid Glass API, Foundation Models Framework)
Complete API references for all frameworks - legacy APIs, current APIs, and newest additions
Code examples with context and explanations across all versions
Human Interface Guidelines (HIG) - Apple's complete design guidelines for all platforms
How it works: Natural language search - ask questions in plain English. Type "how to animate a button press" or "best practices for iOS navigation" and get relevant answers. The search understands concepts and context, not just exact keyword matches.
Database: 16,253+ documents with complete content coverage.
Related MCP server: Apple Deep Docs MCP
npm install apple-docs-mcp-serverThe documentation database (260MB) downloads automatically during installation.
1. Create .cursor/mcp.json in your project root:
{
"schemaVersion": 1,
"mcpServers": {
"apple_docs": {
"command": "/absolute/path/to/node_modules/apple-docs-mcp-server/run-mcp-safe.sh",
"env": {
"OPENAI_API_KEY": "your_openai_api_key_here"
},
"autoStart": true,
"alwaysAllow": ["search_docs", "get_doc", "get_code_examples", "get_stats"],
"timeout": 30000
}
}
}2. Find your correct path:
# In your project directory:
echo "$(pwd)/node_modules/apple-docs-mcp-server/run-mcp-safe.sh"3. Restart Cursor completely
Ask your AI assistant questions about Apple development:
API & Code examples (any version):
"Show me SwiftUI animation code examples"
"How do I use Core Data with CloudKit synchronization?"
"Foundation Models Framework setup and usage examples"
"What's new in UIKit for iOS 26?"
Design & Interface Guidelines:
"Apple's guidelines for button design in iOS apps"
"Best practices for navigation patterns on iPad"
"Accessibility requirements for app icons"
Natural language queries:
"How to handle memory management in SwiftUI?"
"How to implement Liquid Glass effects in my app?"
"Best way to implement dark mode support"
Your AI searches through Apple's complete documentation and provides answers with source links. When documents contain code examples, your AI can extract those examples with full context and explanations.
Complete historical and current coverage: This is the most comprehensive Apple developer documentation collection available. Everything Apple has ever published and continues to publish - from legacy APIs to cutting-edge frameworks, all WWDC sessions from 2019-2025, complete Human Interface Guidelines - all in one searchable database.
Natural language search: Ask questions in plain English. No need to know exact API names or keywords. The search understands what you're trying to accomplish.
Working code examples: Not just documentation text, but actual Swift code with explanations and context across all platform versions.
Fast and local: All documents are processed on your machine. Search results appear instantly without API calls.
From legacy to latest: Whether you need legacy iOS 13 APIs or the newest iOS 26 features like Liquid Glass API - it's all here with complete WWDC 2025 content.
Cursor shows "No tools":
Use absolute paths in .cursor/mcp.json
Make sure run-mcp-safe.sh is executable: chmod +x run-mcp-safe.sh
Restart Cursor completely
OpenAI API key errors:
Put your API key in the env section of mcp.json (recommended)
Check API key format: should start with sk-proj- or sk-
Database errors:
Reinstall if database is missing: npm uninstall apple-docs-mcp-server && npm install apple-docs-mcp-server
Check database file exists: ls -lh node_modules/apple-docs-mcp-server/embeddings.db
search_docs: Search through all Apple documentation and design guidelines
get_doc: Get complete document content by ID
get_code_examples: Extract working Swift code examples from documentation with explanations
get_stats: Database statistics and information
Node.js 18 or later
OpenAI API key
Cursor or compatible MCP client
MIT License - see LICENSE file for details.
This is an unofficial tool for accessing Apple developer documentation. No affiliation with Apple Inc.
đź”— CONTEXTUAL CODE EXTRACTION: Extract code examples from a specific document you already found.
WORKFLOW INTEGRATION: • Use after search_docs: See codeBlocks: 5 → get_code_examples(doc_id) → get those 5 examples • Perfect for AI agents: Found interesting document → extract its code without re-searching • Contextual approach: Work with specific documents rather than broad searches
WHAT YOU GET: • All code examples from the specified document • Full context and explanations around each code block • Categorization and complexity analysis • Same rich metadata as extract_code_examples
USAGE PATTERN:
search_docs("SwiftUI navigation") → find relevant documents
See result shows "codeBlocks: 7"
get_code_examples(document_id) → get all 7 examples with context
PERFECT FOR: AI agents who want to drill down into specific documents after initial search.
| Name | Required | Description | Default |
|---|---|---|---|
| docId | Yes | DOCUMENT ID: The id field from search_docs results. Extract code examples from this specific document. |
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 what the tool returns (all code examples, context, categorization, complexity analysis, metadata) and implies a read-only operation. It doesn't mention auth or error handling, but for a read-only extraction tool, this is reasonably transparent.
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 verbose and somewhat repetitive. It uses multiple sections (WORKFLOW INTEGRATION, USAGE PATTERN, PERFECT FOR) that overlap. While organized with headers, it could be more concise without losing key information.
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?
Given no output schema, the description compensates by listing expected return contents. It covers the tool's role within a broader search workflow. However, it omits potential error cases or authorization requirements, which would make it more complete.
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 coverage is 100% and the description enriches the meaning of docId (from search_docs results) and ties it to a usage pattern. This goes beyond the schema's bare description by providing context and source.
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 the tool extracts code examples from a specific document ('Extract code examples from a specific document you already found'). It differentiates from siblings by emphasizing a contextual, document-specific approach vs. broad search, and references search_docs integration.
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?
Explicitly provides a workflow: 'Use after search_docs', a usage pattern with step-by-step instructions, and highlights it's perfect for AI agents drilling down after initial search. This gives clear when-to-use guidance and distinguishes from search_docs or get_doc.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
đź“– DEEP DIVE: Get complete document content with unlimited size - perfect for thorough analysis.
CONTENT RICHNESS: • FULL TEXT: Complete Apple documentation (up to 18K+ characters) • CODE BLOCKS: Multiple Swift examples with syntax highlighting • METADATA: Content length, code block count, document type • STRUCTURE: Sections, discussions, usage examples
USAGE PATTERNS: • SINGLE DOC: Pass string ID for one document • BATCH ANALYSIS: Pass array of up to 10 IDs for comparison • FOLLOW-UP: Use after search_docs to get complete details of promising results
WHAT YOU GET: • title: Document title • url: Direct link to Apple Developer docs • content: Complete text with markdown formatting • contentLength: Size in characters for analysis • codeBlocks: Number of code examples
STRATEGY: Get full documents when search_docs snippets look promising but lack detail. No size limits - get everything you need for implementation.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses behavior via content richness (full text, code blocks, metadata), batch limits (up to 10 IDs), and return fields. However, there is a minor inconsistency: 'unlimited size' vs. 'up to 18K+ characters', which could confuse agents about actual limits. Still, it provides substantial behavioral context.
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 well-structured with clear sections and emoji headers, making it scannable. It is longer than strictly necessary for one parameter, but each section (content richness, usage patterns, what you get, strategy) earns its place by providing actionable guidance. Slight verbosity prevents a perfect score.
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?
Given the tool has one parameter, no output schema, and no annotations, the description covers all necessary bases: return fields (title, url, content, contentLength, codeBlocks), usage patterns, batch limits, and integration with search_docs. It is fully self-contained for an agent to decide when and how to invoke it.
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 description adds significant meaning beyond the schema by explaining the union type in plain language: 'Pass string ID for one document' vs. 'Pass array of up to 10 IDs for comparison'. It also clarifies that the ID comes from search_docs results and gives usage context, which the raw schema description lacks.
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 opens with a specific verb and resource: 'Get complete document content' with 'DEEP DIVE' and 'unlimited size'. It clearly distinguishes itself from siblings like search_docs by positioning itself as the follow-up tool for full documents, and from get_code_examples and get_stats by focusing on complete content.
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?
Explicit usage patterns are provided, including single document, batch analysis, and a clear follow-up strategy after search_docs. It says 'Use after search_docs to get complete details of promising results' and 'Get full documents when search_docs snippets look promising but lack detail', which directly names the alternative tool and the contextual trigger.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
đź“Š DATABASE OVERVIEW: Quick health check and scope understanding of the Apple documentation database.
DATABASE SCALE: • 16,253 total documents from Apple Developer documentation • text-embedding-3-large model (3072 dimensions) for semantic search • Covers iOS, macOS, watchOS, tvOS, visionOS platforms
WHAT YOU GET: • totalDocuments: Exact count of available docs • model: AI model used for semantic search quality • dimensions: Vector dimensions for search precision • sampleTitles: Random titles to understand content types
WHEN TO USE:
• First interaction: Understand database scope
• Debugging: Verify system is working correctly
• Context setting: Know what's available before searching
• Health check: Confirm database connection
Quick reference: This database contains comprehensive Apple platform documentation with semantic search capabilities.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses the exact output fields and database scale, setting expectations for what the tool returns. It clearly implies a read-only operation without stating it explicitly, but no side effects or hidden behaviors are expected for a stats tool.
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 well-structured with clear sections (DATABASE SCALE, WHAT YOU GET, WHEN TO USE) and bullet points, making it scannable. It is slightly verbose with details like exact document count and model specs, but every section serves a purpose and the key info is front-loaded.
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 tool with no output schema, the description fully covers what the tool does, what it returns, and when to use it. It even notes the scope of the database, giving the agent sufficient context to decide if this tool is needed.
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. The description adds context about what the output means (e.g., sampleTitles are for 'understanding content types'), which is sufficient given no inputs are 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 clearly states the tool is a 'DATABASE OVERVIEW' and a 'health check', providing a specific purpose that distinguishes it from siblings like search_docs and get_doc. It lists what users 'get' (totalDocuments, model, dimensions, sampleTitles), making its function concrete.
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?
An explicit 'WHEN TO USE' section lists four distinct scenarios (first interaction, debugging, context setting, health check), giving clear guidance on when to invoke this tool. While it doesn't explicitly mention alternatives, it frames usage as 'before searching', implying a complementary role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
🔍 SEMANTIC SEARCH through 16,253 Apple documentation pages with intelligent relevance scoring.
SEARCH STRATEGY: • BROAD→NARROW: Start with general concepts ("SwiftUI animation") then narrow down ("SwiftUI keyframe animator") • ITERATE: If results aren't specific enough, reformulate with more precise terms • EXPLORE: Use limit 8-10 for initial exploration, limit 3-5 for focused searches • 🔗 RELATED MODE: Set includeRelated=true to auto-discover connected topics
QUERY EXAMPLES:
âś… GOOD: "SwiftUI custom transition animation", "Core Data CloudKit conflict resolution"
âś… GOOD: "NSFetchRequest predicate performance", "UIKit navigation controller delegate"
✅ WITH RELATED: "SwiftUI Button" + includeRelated=true → 3 main + 5 related (ButtonStyle, UIButton, design guidelines) = comprehensive topic coverage
❌ AVOID: Single words like "Button" or "Core Data" - too broad
❌ AVOID: Non-Apple terms like "React" or "Android"
RELEVANCE SCORES:
• 60%+: Highly relevant, likely contains what you need
• 50-59%: Good match, worth investigating
• 40-49%: Partial match, may have related information
• <40%: Weak match, consider refining search
🔗 ENHANCED BY DEFAULT: Every search includes 3-6 intelligently related documents • Semantic similarity using existing embeddings (NO extra OpenAI API calls!) • Intelligent relationship classification: 🔄 Migration, 🆕 Alternatives, ⚡ Performance, 📋 Examples • Smart threshold adaptation based on main result quality (75-85% similarity scores) • Framework-aware connections: SceneKit→RealityKit, UIKit→SwiftUI, Core Image→Metal • Quality-first approach: vector-based semantic matching replaces keyword search • Use includeRelated=false to disable and get only main search results
WORKFLOW: Use search_docs for exploration → get_doc for detailed analysis → repeat with refined queries.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | RESULT COUNT: 8-10 for exploration, 3-5 for focused search. More results = broader overview. | |
| query | Yes | SEARCH QUERY: Use 2-4 specific keywords. Examples: "SwiftUI custom animation", "Core Data fetch performance", "UIKit navigation delegate methods" | |
| minSimilarity | No | RELEVANCE THRESHOLD: 0.3 (default) for broad search, 0.5+ for highly specific results. Lower = more results. | |
| includeContent | No | CONTENT PREVIEW: Always true for decision making. Provides snippet to evaluate relevance. | |
| includeRelated | No | 🔗 VECTOR-BASED AUTO-DISCOVER: Find semantically related documents using embeddings similarity (NOW ENABLED BY DEFAULT). Adds 3-6 intelligently classified docs (🔄 Migration guides, 🆕 Modern alternatives, ⚡ Performance tips, 📋 Code examples). Set to false to show only main results. | |
| maxContentChars | No | SNIPPET SIZE: 150-200 for quick scan, 300+ for detailed preview. Balance overview vs detail. | |
| showCodePreview | No | đź’» CODE PREVIEW: Show preview of first Swift code block in each result. Perfect for AI agents to quickly see if document contains useful code examples. Use with get_code_examples(docId) for full code extraction. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries behavioral disclosure. It reveals that related results are enabled by default (3-6 docs), that semantic matching uses existing embeddings with no extra API calls, that relevance thresholds and related-doc similarity adaptation occur, and that includes framework-aware connections. This goes far beyond a basic search description.
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 long but highly organized with clear sections, examples, and emoji signposts. It is front-loaded with purpose and strategy. Some redundancy exists between the 'ENHANCED BY DEFAULT' section and the includeRelated parameter description, so it is not perfectly concise, but the density is justified by the tool's feature richness.
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?
Given no output schema, the description covers return semantics effectively: relevance score bands, related-document counts, and a concrete example of the related mode result structure. It also addresses the full workflow with siblings and parameter trade-offs, making it complete for an AI agent to select and 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?
Schema coverage is 100%, so the baseline is 3, but the tool description adds substantial value beyond the schema: it explains how to interpret relevance scores (60%+, 50-59%, etc.), gives query examples matching the format, and describes practical limit/minSimilarity settings. The includeRelated behavior and showCodePreview integration with get_code_examples are also elaborated beyond raw parameter docs.
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 opens with 'SEMANTIC SEARCH through 16,253 Apple documentation pages with intelligent relevance scoring,' which clearly names the verb, resource, and unique value. It distinguishes from siblings by explicitly positioning search_docs for exploration versus get_doc for detailed analysis and get_code_examples for code extraction.
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?
Provides a detailed SEARCH STRATEGY with broad-to-narrow iteration, specific limit recommendations, query examples with good and bad patterns, and explicit alternatives (get_doc, get_code_examples). The workflow line 'Use search_docs for exploration → get_doc for detailed analysis → repeat' makes when-to-use unmistakable.
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. Dates show when Glama detected each change.
v2.4.0get_code_examplesget_docget_statssearch_docsEach tool has a clearly distinct purpose: stats overview, semantic search, full document retrieval, and code extraction. There is no overlap between search_docs, get_doc, and get_code_examples, as each serves a specific step in the documentation workflow.
All tool names follow a consistent verb_noun pattern with snake_case: get_stats, search_docs, get_doc, get_code_examples. The verbs and nouns are predictable and accurately reflect the tool's function.
With 4 tools, the server is well-scoped for its purpose of searching and retrieving Apple documentation. Each tool is essential and the small count keeps the surface manageable without feeling sparse.
The server covers the full lifecycle of accessing documentation: understanding scope (get_stats), searching (search_docs), reading full content (get_doc), and extracting code examples (get_code_examples). For a read-only documentation server, this is a complete and practical set with no obvious dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Apple Developer Documentation with Semantic Search, RAG, and AI reranking for MCP clients
The documentation, as a tool your agent can call: 950+ AI-dev guides. Search + fetch tools.
Search and read Rust documentation for the standard library and any crate on crates.io
Get up-to-date, version-specific documentation and code examples from official sources directly in…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bbssppllvv/apple-docs-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
