Skip to main content
Glama

search_apple_docs

Read-only

Search Apple Developer Documentation to find specific APIs, classes, methods, frameworks, guides, and code samples. Use it to locate precise technical information.

Instructions

Search Apple Developer Documentation for APIs, frameworks, guides, and samples. Best for finding specific APIs, classes, or methods. Latency: typically 5-25 seconds (median about 10) because Apple streams the full result set; repeated identical queries are cached for 10 minutes. For browsing sample code projects, use get_sample_code. For WWDC videos, use the dedicated WWDC tools (list_wwdc_videos, search_wwdc_content).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoType of content to filter. Use "all" for comprehensive results, "documentation" for API references/guides, "sample" for code snippets. Note: "sample" returns individual code examples, not full projects. For complete sample projects, use get_sample_code instead. Default: "all".
queryYesSearch 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".
selectNoJev semantic selection: score the results against the query and return only the best 1-5, each with a relevance score. Default: on when APPLE_DOCS_MCP_JEV_RERANK=1 is set, otherwise off. select: true while it is not enabled is an error. Adds a Jev provider call (up to about 15 s).
maxResultsNoWith select on: the most results to return (1-5, default 5). Ignored with select off.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.1.1

TDQS

A4.4/5.0
Behavior4/5

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

Annotations only declare readOnlyHint, so the description carries most of the burden and does well: it discloses expected latency (5-25s, median ~10), the reason (Apple streams full result set), and a 10-minute cache for identical queries. It omits any auth or failure-mode behavior, which keeps it from a 5.

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

Conciseness5/5

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

Four sentences, zero filler: purpose first, usage guidance second, then performance/caching caveat, then sibling routing. Each sentence carries distinct decision-relevant information.

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

Completeness4/5

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

Covers purpose, alternatives, latency, and caching for a search tool with no output schema and fully documented parameters. The only gap is a brief note on what results look like or how to page beyond maxResults, which is minor here.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents query tips, the type enum, select semantics, and maxResults interaction. The description adds no per-parameter detail beyond that, so the baseline 3 applies.

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 (Search) plus resource (Apple Developer Documentation) and the content classes covered (APIs, frameworks, guides, samples). It explicitly differentiates from siblings by naming get_sample_code and the WWDC tools as separate routes.

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 an explicit use case ('Best for finding specific APIs, classes, or methods') and then routes two other intents away: sample projects to get_sample_code, WWDC videos to list_wwdc_videos/search_wwdc_content. When-to-use and when-not-to-use are both present.

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