Loading ToolBench
Navigate Swift code without grep. Semantic code navigation for Swift, Objective-C, C and C++ with symbol lookup, impact analysis, structural search, and repository mapping.
Sextant defines 13 code-analysis tools with complete input schemas and strong descriptions (avg 180 chars, well above 10-char minimum). All tools are read-only, reducing security risk. Naming is verb-forward and clear (context, blast_radius, find_references). However, output schemas are entirely undocumented, LLMs cannot predict response structure or plan downstream calls. Parameter descriptions are minimal (1-2 sentences); none explain expected formats, ranges, or error conditions. No error handling guidance. Tool composition is sound (each does one thing), but lack of output documentation and error recovery patterns prevents this from reaching 80+.
Public surface of a package or type — signatures plus doc summaries, without reading files. An order of magnitude cheaper than reading the sources. Covers Swift, Objective-C, C and C++ (C++ headers need the flags from `sextant index`, which RUNS the project's build (its manifest, plugins and macros are code) — so it is the user's call, not an automatic step). Narrow it with package, type, or scope.
Impact analysis: what a change to this symbol would touch (affected files, usages, calls, implementations).
Full source text of a declaration, signature AND body, by name. Use when you need the implementation; defs and context give only the signature.
Transitive call graph, rendered as a tree.
Symbol-level git diff: which declarations were added, removed, or changed signature between revisions. Not a line diff. Use for 'what changed' and 'what did I break'. Covers Swift, Objective-C, C and C++ (the last three need the flags from `sextant index`, which RUNS the project's build (its manifest, plugins and macros are code) — so it is the user's call, not an automatic step); a file that could not be compared is listed with the reason, so an empty result never means it is unchanged.
Output schemas completely undocumented. No tool declares what fields it returns, data types, or structure. LLMs cannot predict response format or plan multi-step calls. This violates pattern:tool and pattern:response-shaper.
No error handling guidance. Tools provide no recovery hints, error classification, or actionable messages. If a symbol is not found or a search fails, LLMs have no guidance on what to try next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Everything about one symbol in a single call: definition, usages, callers, callees, hierarchy. Prefer this over a series of greps.
Call sites of a function or method, accounting for protocol dispatch. A TYPE has no call sites — use find_references or context for those.
Every usage of a symbol.
Structural code-hygiene rules (the set from .sextant.json, otherwise the built-in one). Covers Swift plus Objective-C, C and C++; a file where no rule could be checked is listed with the reason, so a clean report never covers unread code.
Implementations and subtypes of a protocol or class.
Repository map: public and internal types by file, symbol-level.
Structural search over the AST, replacing grep: metavariables $X, variadic $$$, statement patterns. For example 'try? $X.save()' in Swift or '[$X reloadData]' in Objective-C. Swift is matched by its own parser; Objective-C, C and C++ by clang, which needs the flags from `sextant index`, which RUNS the project's build (its manifest, plugins and macros are code) — so it is the user's call, not an automatic step. Files that could not be read are listed with the reason, so 'no matches' never quietly covers them. Occurrences inside #if branches this build does not contain are reported separately as textual, NOT structurally verified — treat them as leads, not as matches.
Where a symbol is defined (file:line).
Parameter descriptions lack format/constraint details. E.g., 'symbol' param has no guidance on case sensitivity, namespace syntax, or what happens if symbol is ambiguous. 'budget' in repo_map has no min/max bounds.
lint tool has empty inputSchema properties dict. No parameters are documented, making it unclear what configuration or filtering options exist.
structural_search description is verbose (400+ chars) and buries key details in caveats about #if branches and clang flags. Simplify to 150-200 chars with caveats in a separate 'Notes' section or error responses.