Skip to main content
Glama
Sign In
Apple Docs 2.0 MCP

Apple Docs 2.0 MCP

by mishafyi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Search Apple Docs

search_apple_docs
Read-only

Find Apple developer pages by topic or functionality, including API references, articles, sample code, HIG, App Store Connect Help, and WWDC sessions. Returns links with titles, kinds, and summaries.

Instructions

Search Apple's developer site the way developer.apple.com/search does, best match first: API reference, articles, sample code, the Human Interface Guidelines, App Store Connect Help and WWDC sessions. Use it to find pages by what they do or are about ("SwiftUI haptic feedback", "TestFlight external testers"); for a name you already know, search_docs_map answers at once. Returns links, each with its title, framework, kind and one-line summary; read a page with get_apple_doc_content, a session with get_wwdc_video. For sample code, type "sample" ranks every sample project on the site, including ones Apple's Sample Code Library doesn't list; for WWDC sessions, type "video". Searches run one at a time, 15 s apart, so several in a row are slow.

Input Schema

NameRequiredDescriptionDefault
typeNoLeave out to search everything, as Apple's search page does with no filter; WWDC sessions show only where Apple mixes them in. "documentation": API reference and articles; "design": the Human Interface Guidelines; "sample": sample code projects; "help": App Store Connect Help (product page, review, TestFlight, pricing); "video": WWDC sessions alone.
queryYesWhat you're looking for, in words or by name: "SwiftUI haptic feedback", "NSPredicate", "TestFlight external testers". Every word counts. A full list doesn't mean a match: when little fits, the list fills up with weaker results.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.1.1
    • changedInput schema / properties / query / description
      Previous value: -"Search query for Apple Developer Documentation. Tips: Use specific API names (e.g., \"UIViewController\"), framework names (e.g., \"SwiftUI\"), or technical terms. Avoid generic terms like \"how to\" or \"tutorial\". Examples: \"NSPredicate\", \"SwiftUI List\", \"Core Data migration\", \"URLSession authentication\"."New value: +"What you're looking for, in words or by name: \"SwiftUI haptic feedback\", \"NSPredicate\", \"TestFlight external testers\". Every word counts. A full list doesn't mean a match: when little fits, the list fills up with weaker results."
    • addedInput schema / properties / query / minLength
      Added value: +1
    • removedInput schema / properties / type / default
      Removed value: -"all"
    • changedInput schema / properties / type / description
      Previous value: -"Type of content to filter. \"all\": documentation, design guidelines, sample code projects, and WWDC sessions; \"documentation\": API references and guides; \"design\": the Human Interface Guidelines; \"sample\": sample code projects; \"help\": App Store Connect Help (product page fields, review, TestFlight, pricing). Default: \"all\"."New value: +"Leave out to search everything, as Apple's search page does with no filter; WWDC sessions show only where Apple mixes them in. \"documentation\": API reference and articles; \"design\": the Human Interface Guidelines; \"sample\": sample code projects; \"help\": App Store Connect Help (product page, review, TestFlight, pricing); \"video\": WWDC sessions alone."
    • changedInput schema / properties / type / enum
      Previous value: -[
-  "all",
-  "documentation",
-  "design",
-  "sample",
-  "help"
-]New value: +[
+  "documentation",
+  "design",
+  "sample",
+  "help",
+  "video"
+]
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true, and the description goes well beyond that: it discloses result ordering ('best match first'), the return shape (links with title, framework, kind, one-line summary), the ranking caveat that a full list means weak matches, and a real constraint (searches run one at a time, 15 s apart). That is unusually rich 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.

Conciseness4/5

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

Front-loaded with purpose and the sibling distinction, then usage, then return format, then the rate limit. Dense and parenthetical-heavy ('the way developer.apple.com/search does', repeated quoted examples), but nearly every clause carries routing or behavioral information.

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?

No output schema exists, and the description compensates by describing exactly what comes back and how to consume it via get_apple_doc_content/get_wwdc_video. Combined with type semantics, ranking caveats, and the rate limit, nothing an agent needs to call this correctly is missing.

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: it explains that omitting type mirrors Apple's unfiltered search, that 'sample' surfaces projects Apple's own library omits, and how word count affects match quality. It stops short of restating query syntax details fully, so not a 5.

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 and resource ('Search Apple's developer site'), enumerates the content classes it covers, and explicitly distinguishes itself from search_docs_map ('for a name you already know'). An agent can route between the two search tools without opening either schema.

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

Usage Guidelines5/5

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

Gives when-to-use with example queries, names the alternative for known-name lookups, and points to get_apple_doc_content and get_wwdc_video for consuming results. The per-type guidance ('for sample code, type "sample"', 'for WWDC sessions, type "video"') is explicit routing advice.

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

Deploy Server

Other Tools