Provides access to Apple's Human Interface Guidelines and technical API documentation across all Apple platforms (iOS, macOS, watchOS, tvOS, visionOS), combining design principles with implementation details for comprehensive Apple development guidance.
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 Dev MCP Server search unified for iOS navigation patterns"
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.
Complete Apple development guidance for AI assistants
Combines Human Interface Guidelines (design) with Technical Documentation (API reference) for all Apple platforms.
🎨 Complete Coverage: HIG design guidelines + Apple API documentation for iOS, macOS, watchOS, tvOS, visionOS
⚡ Smart Caching: Fast responses via intelligent caching with graceful degradation
🔍 Smart Search: Unified search across design and technical content
🤖 Enhanced Search: Advanced search combining design principles with technical implementation
📚 Pre-built Content: 113+ pre-processed Apple HIG sections for instant access
Related MCP server: Apple RAG MCP
Download apple-dev-mcp.dxt from releases
Double-click to install in Claude Desktop
Restart Claude Desktop
Start using Apple development guidance!
npm install -g apple-dev-mcpAdd to claude_desktop_config.json:
{
"mcpServers": {
"Apple Dev": {
"command": "node",
"args": ["/usr/local/lib/node_modules/apple-dev-mcp/dist/server.js"]
}
}
}claude mcp add "Apple-Dev" node /usr/local/lib/node_modules/apple-dev-mcp/dist/server.jsCreate .cursor/mcp.json, windsurf config, or .vscode/mcp.json:
{
"mcpServers": {
"Apple Dev": {
"command": "node",
"args": ["/usr/local/lib/node_modules/apple-dev-mcp/dist/server.js"]
}
}
}Find your path: npm list -g apple-dev-mcp
Windows users: Replace with C:\Users\YourUsername\AppData\Roaming\npm\node_modules\apple-dev-mcp\dist\server.js
Design Guidelines Search
search_human_interface_guidelines - Search Apple HIG with platform filters
Returns full content (not snippets) for AI-friendly responses
Covers all Apple platforms: iOS, macOS, watchOS, tvOS, visionOS
Technical Documentation Search
search_technical_documentation - Search Apple API documentation
Framework-specific searches (SwiftUI, UIKit, AppKit, etc.)
Symbol and method lookups with code examples
Unified Search
search_unified - Combined design + technical documentation search
Cross-references design guidelines with implementation details
Perfect for end-to-end development guidance
Search Design Guidelines:
{
"name": "search_human_interface_guidelines",
"arguments": {
"query": "Tab Bars",
"platform": "iOS"
}
}Search Technical Documentation:
{
"name": "search_technical_documentation",
"arguments": {
"query": "Button",
"framework": "SwiftUI"
}
}Unified Search:
{
"name": "search_unified",
"arguments": {
"query": "navigation",
"platform": "iOS"
}
}npm test # Run test suite
npm test # Test functionality
# Interactive testing
npx @modelcontextprotocol/inspector apple-dev-mcpWe welcome contributions! The most needed help:
Scraper fixes when Apple changes their website
New features and bug fixes
Documentation improvements
See CONTRIBUTING.md for guidelines.
This project operates under fair use principles for educational purposes. All content includes proper Apple attribution and respects their intellectual property.
Content sourced from Apple's Human Interface Guidelines.
© Apple Inc. All rights reserved. Provided for educational purposes.
MightyDillah for inspiration
Apple Inc. for comprehensive design guidelines
Open source community for contributions
Built with ❤️ for the developer community
Bringing Apple's design excellence directly to your AI-assisted development workflow.
Search Apple Human Interface Guidelines by keywords
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (keywords, component names, design concepts) | |
| platform | No | Optional: Filter by Apple platform |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description lacks details on behavioral traits such as result format, limits, or side effects.
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?
Very concise single sentence, front-loaded, but may be too minimal for full clarity.
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 simple search tool with no output schema or annotations, the description is too brief and lacks necessary context.
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 adds no extra meaning beyond the schema; baseline is appropriate.
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 searches Apple Human Interface Guidelines by keywords, but it does not differentiate from sibling tools like search_technical_documentation or search_unified.
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?
No guidance on when to use this tool versus alternatives; no when-not or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Apple technical documentation and API references
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (API names, symbols, frameworks) | |
| platform | No | Optional: Filter by platform (iOS, macOS, etc.) | |
| framework | No | Optional: Search within specific framework (e.g., "SwiftUI", "UIKit") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only says 'Search' without disclosing behavioral traits like read-only nature, rate limits, or result format. Minimal 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?
Single sentence, concise and front-loaded. Appropriate length, but could use more detail without being verbose.
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 and no annotations, the description is too minimal. Lacks details on result handling, pagination, or scope of documentation covered.
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 baseline is 3. The description adds no extra meaning beyond what is already in the parameter descriptions.
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 it searches Apple technical documentation and API references. It uses a specific verb and resource but does not explicitly differentiate from sibling tools like search_human_interface_guidelines.
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?
No guidance on when to use this tool versus alternatives, no context about prerequisites or intended use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unified search across both HIG design guidelines and technical documentation
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (keywords, component names, design concepts) | |
| platform | No | Optional: Filter by Apple platform |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only states the scope (both guidelines and technical docs) but omits any details about result ranking, filtering behavior, or limitations of the unified search.
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 concise sentence that efficiently conveys the core purpose. It is front-loaded and has no wasted words, though it could be slightly expanded without harming conciseness.
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 absence of an output schema and the tool's role as a search function, the description is too minimal. It does not explain result format, ordering, or how the unified search behaves compared to individual searches, leaving the agent underinformed.
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% with descriptions for both 'query' and 'platform'. The description adds little beyond the schema, merely reinforcing that the search covers both documentation types. Baseline of 3 is appropriate.
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 it performs a unified search across HIG design guidelines and technical documentation, which distinguishes it from the sibling tools that search each individually. However, it could be more explicit about combining results rather than searching across both separately.
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?
No guidance is provided on when to use this unified search versus the specific sibling tools. It does not mention scenarios where a combined search is preferred or when to use the individual tools instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct target: HIG, technical docs, or unified search. The unified tool overlaps but serves a combined purpose, so there is slight potential for confusion, but overall they are clearly distinguishable.
All tools follow a consistent 'search_<descriptive_suffix>' pattern, making it easy for agents to predict and understand tool purposes.
With only three tools, the server is well-scoped for its purpose of searching Apple documentation, avoiding unnecessary complexity while covering key search scenarios.
The set covers both major documentation areas (HIG and technical) with individual and unified search. Minor gaps like sample code search exist but are outside the stated scope.
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.
Provides AI assistants with direct access to Mapbox developer APIs and documentation.
Give AI assistants access to real-time data. Search the web, compare flights, find hotels, and more.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tmaasen/apple-dev-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
