Apple Docs 2.0 MCP

Get Apple Doc Content

get_apple_doc_content

Read-only

Fetch any Apple developer documentation page by URL and return its full Markdown content, covering APIs, tutorials, samples, HIG, and App Store Connect help.

Instructions

Read one page of Apple's developer documentation by its URL: an API, article, sample project, tutorial, Human Interface Guidelines page, App Store Connect Help article or web-service endpoint (App Store Connect API, App Store Server API and the like). Returns the whole page as Markdown: summary, declarations, overview with its code, each member with its declaration and summary, relationships, the versions it's available in on each platform with Apple's notes, and See Also; for a sample, its Download link; for a tutorial, its steps with their code; for an endpoint, its URL, parameters and responses. Use it on a search result's link or a URL you already have; language "occ" reads an API's Objective-C version. A view answers one question about an API in less: "related" (what it inherits, conforms to and lists, with summaries), "similar" (what to use instead, led by the pages its deprecation note names), "references" (the pages it links to, with their summaries) or "availability" (the versions that introduced and deprecated it on each platform).

Input Schema

Name	Required	Description	Default
`url`	Yes	The page's address on developer.apple.com, under /documentation/, /design/human-interface-guidelines/, /tutorials/ or, for view "page" only, /help/app-store-connect/ ("https://developer.apple.com/documentation/swiftui/navigationstack"). Take it from a result or a link: a guessed one often doesn't exist.
`view`	No	"page": the whole page. The others give one part of an API's page, shorter. "related": what it inherits from and what inherits from it, the protocols it conforms to and the types that conform to it, and its See Also list, each with its one-line summary, plus the first 3 members of each Topics group. "similar": what to use instead or alongside, each with its summary: first the pages its deprecation note names, then its See Also list, then members of its Topics groups; for replacing a deprecated API. "references": the pages it links to, from its lists and inside its text, each with its summary and, for an API, its declaration, grouped by Apple's role for each ("symbol", "article", "collection"). "availability": the title, tagged Deprecated or Beta as Apple's page tags it, and each platform with the version that introduced it and, where deprecated, the version and Apple's note.	page
`language`	No	"swift": the page in Swift; "occ": an API's Objective-C version, its declaration and members as Objective-C writes them. A page Apple writes in Swift alone has none. The views other than "page" read the Swift page.	swift
`searchDepth`	No	similar: "shallow", the pages the deprecation note names and the See Also list, up to 5; "medium", also the first 4 members of each Topics group, up to 10; "deep", also the See Also lists of the first 3 results, up to 15.	medium
`filterByType`	No	references: keeps the linked pages of one role or kind, as Apple names them: "symbol" (APIs), "collection", "article", "sampleCode" and the like.	all
`maxReferences`	No	references: most linked pages to show, not by relevance: those its lists name (Topics, Relationships, See Also) first, then those its text links to.

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv0.1.1Oct 18, 2026

addedInput schema / properties / filterByType

Added value: +{
+  "default": "all",
+  "description": "references: keeps the linked pages of one role or kind, as Apple names them: \"symbol\" (APIs), \"collection\", \"article\", \"sampleCode\" and the like.",
+  "enum": [
+    "all",
+    "symbol",
+    "containerSymbol",
+    "restRequestSymbol",
+    "dictionarySymbol",
+    "pseudoSymbol",
+    "pseudoCollection",
+    "collection",
+    "collectionGroup",
+    "article",
+    "sampleCode",
+    "overview",
+    "table",
+    "codeListing",
+    "link",
+    "project",
+    "subsection",
+    "task",
+    "section",
+    "root"
+  ],
+  "type": "string"
+}

removedInput schema / properties / includePlatformAnalysis

Removed value: -{
-  "default": false,
-  "description": "Analyze platform availability and version requirements. Essential for cross-platform development. Default: false",
-  "type": "boolean"
-}

removedInput schema / properties / includeReferences

Removed value: -{
-  "default": false,
-  "description": "Resolve and include all referenced types and APIs. Helps understand dependencies. Default: false",
-  "type": "boolean"
-}

removedInput schema / properties / includeRelatedApis

Removed value: -{
-  "default": false,
-  "description": "Include inheritance hierarchy and protocol conformances. Useful for understanding API relationships. Default: false",
-  "type": "boolean"
-}

removedInput schema / properties / includeSimilarApis

Removed value: -{
-  "default": false,
-  "description": "Discover APIs with similar functionality. Great for finding alternatives. Default: false",
-  "type": "boolean"
-}

addedInput schema / properties / language

Added value: +{
+  "default": "swift",
+  "description": "\"swift\": the page in Swift; \"occ\": an API's Objective-C version, its declaration and members as Objective-C writes them. A page Apple writes in Swift alone has none. The views other than \"page\" read the Swift page.",
+  "enum": [
+    "swift",
+    "occ"
+  ],
+  "type": "string"
+}

addedInput schema / properties / maxReferences

Added value: +{
+  "default": 20,
+  "description": "references: most linked pages to show, not by relevance: those its lists name (Topics, Relationships, See Also) first, then those its text links to.",
+  "maximum": 50,
+  "minimum": 1,
+  "type": "number"
+}

addedInput schema / properties / searchDepth

Added value: +{
+  "default": "medium",
+  "description": "similar: \"shallow\", the pages the deprecation note names and the See Also list, up to 5; \"medium\", also the first 4 members of each Topics group, up to 10; \"deep\", also the See Also lists of the first 3 results, up to 15.",
+  "enum": [
+    "shallow",
+    "medium",
+    "deep"
+  ],
+  "type": "string"
+}

changedInput schema / properties / url / description

Previous value: -"Full URL of the Apple Developer Documentation page. Must start with https://developer.apple.com/documentation/, https://developer.apple.com/design/human-interface-guidelines/, https://developer.apple.com/tutorials/ or https://developer.apple.com/help/app-store-connect/. Example: \"https://developer.apple.com/documentation/uikit/uiviewcontroller\""New value: +"The page's address on developer.apple.com, under /documentation/, /design/human-interface-guidelines/, /tutorials/ or, for view \"page\" only, /help/app-store-connect/ (\"https://developer.apple.com/documentation/swiftui/navigationstack\"). Take it from a result or a link: a guessed one often doesn't exist."

addedInput schema / properties / view

Added value: +{
+  "default": "page",
+  "description": "\"page\": the whole page. The others give one part of an API's page, shorter. \"related\": what it inherits from and what inherits from it, the protocols it conforms to and the types that conform to it, and its See Also list, each with its one-line summary, plus the first 3 members of each Topics group. \"similar\": what to use instead or alongside, each with its summary: first the pages its deprecation note names, then its See Also list, then members of its Topics groups; for replacing a deprecated API. \"references\": the pages it links to, from its lists and inside its text, each with its summary and, for an API, its declaration, grouped by Apple's role for each (\"symbol\", \"article\", \"collection\"). \"availability\": the title, tagged Deprecated or Beta as Apple's page tags it, and each platform with the version that introduced it and, where deprecated, the version and Apple's note.",
+  "enum": [
+    "page",
+    "related",
+    "similar",
+    "references",
+    "availability"
+  ],
+  "type": "string"
+}

First observedv0.1.0Oct 15, 2026

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With only readOnlyHint=true in annotations, the description carries the behavioral burden and does so: it details what each view returns, notes that 'occ' yields nothing for Swift-only pages, that non-'page' views read the Swift page, and that invented URLs usually 404. These are real operational constraints an agent could not infer from the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and return shape are front-loaded, which is good, but the body is one dense paragraph of long nested clauses that is hard to scan. Nearly every sentence carries information, yet the run-on construction and heavy enumeration of view internals cost readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and six parameters, so the description must explain the returns — and it does so per view, per page type and per language, covering everything needed to call the tool correctly and interpret its output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 description adds genuine meaning on top: the decision rule for 'similar' (deprecation-note pages first, then See Also, then Topics) and the use case 'for replacing a deprecated API', plus 'occ' semantics for an API's declaration and members.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Read one page of Apple's developer documentation by its URL') and enumerates the page classes it covers (API, article, sample, tutorial, HIG, ASC Help, endpoint). It also implicitly differentiates from the search/lookup siblings by being the retrieval step for a URL the agent already has.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use it on a search result's link or a URL you already have' gives a clear when-to-use condition tied to the sibling search tools, and the url parameter warns that guessed URLs often don't exist. It stops short of naming search_apple_docs explicitly or stating when not to use this tool, so it is clear context rather than full routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Get Apple Doc Content

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools