Loading ToolBench
MCP server exposing Swift docs search, evolution lookup, lint, format, and guidelines checks.
This server provides 17 tools with explicit registration via Zod schemas and descriptions. However, quality is inconsistent across tools. Strengths: all tools have basic descriptions and schemas are present with type definitions. Weaknesses: descriptions are generic and often lack context for when/why to use the tool; parameter descriptions are minimal or absent in many cases; output schemas are undocumented; no error handling guidance. The naming is generally good (action verbs: search, lookup, run, apply, check, etc.), but descriptions fail to explain prerequisites, return types, or distinguish between similar tools (e.g., swift_docs_search vs apple_docs_search vs search_hybrid are unclear in when to use each). Parameter handling is weak, many optional parameters lack explanation of what happens when omitted. No output schemas documented anywhere, so LLMs cannot plan downstream calls or extract chaining IDs. Error handling is absent from descriptions; tools simply return JSON with no guidance on failure modes or recovery.
Auto-fetch Apple documentation from developer.apple.com. Can target specific frameworks or auto-detect from a Swift project.
Search Apple docs (DocC/docsets). Filters by frameworks optionally.
Import Apple DocC/Dash content from a path or URL into .cache/apple-docs/<Framework>/ and reindex.
Search curated Cocoa patterns (keyboard/focus/window).
Search macOS HIG snapshots (local cache).
Report cache directory and index statuses (apple/hig/patterns/hybrid).
Hybrid search across Apple DocC, HIG, TSPL (Swift book), curated patterns, and recipes with facet filters; returns { results, facets } with facet counts.
Output schemas undocumented. No tool documents what fields or structure it returns, preventing LLMs from planning downstream calls or extracting chaining IDs (e.g., does apple_docs_search return framework_id, symbol_id, and other fields needed by subsequent tools?).
Parameter descriptions missing or trivial. Most optional parameters lack explanation of what happens when omitted or what valid values are expected. E.g., 'limit' has description 'Maximum number of results' but does not state default, minimum, or maximum bounds.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Search Swift docs (TSPL + API Design Guidelines)
Lookup Swift Evolution proposals by ID or keyword
Format Swift code using swift-format or SwiftFormat
Run heuristic Swift API Guidelines checks on code
Run SwiftLint on a path
Scan a Swift project directory to discover which frameworks are imported. Returns sorted list by priority.
Lookup Swift development recipes (YAML-backed).
Generate a Swift Package with a video overlay module scaffold.
Resolve a Swift symbol/selector to Apple docs hits.
Mirror swift-evolution and swift-book into .cache for offline queries
Generic tool descriptions lack context for selection. Descriptions like 'Search Swift docs' and 'Search Apple docs' do not explain when to use swift_docs_search vs apple_docs_search vs search_hybrid, or what differences in content/scope each provides. LLMs will guess incorrectly.
No error handling guidance. Tool descriptions do not explain failure modes, what errors can occur, or how to recover. E.g., swift_lint_run may fail if SwiftLint is not installed, but description says nothing about graceful degradation or retry logic.
Destructive operations lack confirmation or dry-run support. swift_update_sync (WRITE), apple_docsets_import (WRITE), swift_scaffold_module (WRITE), and apple_docs_populate (WRITE) have no mention of dry-run, preview, or confirmation steps to prevent accidental data loss or file overwrites.
Enum constraints missing. apple_docs_populate.depth is described as 'Search depth (1-3)' but is not declared as an enum; swift_scaffold_module correctly uses enums for platform and overlayStyle, but other tools with constrained values do not.
Pagination not supported or documented. Tools like apple_docs_search and search_hybrid accept 'limit' but do not mention offset, cursor, or total_count. Large result sets could blow context windows without pagination.
Overlapping tool purpose without clear differentiation. swift_docs_search (TSPL + API Design Guidelines) vs apple_docs_search (DocC/docsets) vs search_hybrid (all sources) are confusing. Tool descriptions do not explain why an LLM should choose one over another.
Natural identifiers not accepted. Tools require opaque paths, framework names, or query strings but do not indicate whether they accept human-friendly names (e.g., does apple_docs_populate accept 'SwiftUI' or require 'com.apple.SwiftUI'?).