Loading ToolBench
Token-efficient code retrieval for agents: FTS5 search, symbol outlines, surgical reads.
Lens demonstrates solid tool design with clear, action-oriented naming (lens_search, lens_index, lens_read) and comprehensive descriptions (avg 180 chars, well within 10-1024 range). All 8 tools have explicit input schemas with type definitions and parameter descriptions. Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are correctly declared. However, output schemas are not documented, LLMs cannot predict return structure. Error handling is minimal; no recovery guidance or actionable error messages visible in code. Parameter descriptions lack format constraints (e.g., max_tokens range, path_glob pattern syntax). The lens_read tool's max_tokens description is verbose but lacks min/max bounds. No validation of required parameters shown in handler.
Is the index STALE? Compares the code on disk now against what was indexed, and reports which files changed, were added, or were removed since. Check this before you trust a lens_search on a repo you indexed earlier — a search answers from the index, so if the code moved on you get yesterday's answer with no warning. If stale is non-zero, run lens_index again.
Index (or incrementally refresh) a file or directory so it can be searched. Run once per repo, then again after edits (only changed files are re-read).
List the indexed files and language breakdown — a quick map of the repo.
Get a compact symbol map (functions, classes, headings) of a file with line numbers — understand structure without reading the whole file.
Read an exact line range of a file (surgical). Pair with lens_search / lens_outline to pull only the lines you need.
Find every line across the index that mentions a symbol (whole-word), grouped by file with line numbers. Use to see where a function/variable/class is used or defined before editing it.
Output schemas not documented. LLMs cannot predict return structure (fields, types, pagination). Lens_search, lens_references, lens_outline, lens_read, lens_map all lack documented return types.
No input validation or error recovery guidance in handler. Comment at line ~50 notes that missing required 'query' param causes deep stack trace ('Cannot read properties of undefined'). Errors should be caught early with actionable messages like 'query is required'.
Parameter constraints missing. lens_read max_tokens lacks min/max bounds (default 4000, but no range stated). lens_search k and max_tokens have no bounds. lens_references limit has no bounds. Unbounded numbers let LLMs pass absurd values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Search the indexed codebase and get back the most relevant code snippets (ranked, with file:line), within a token budget. Use this INSTEAD of reading whole files — it is far cheaper.
Index statistics: file/chunk/line counts and languages.
lens_map and lens_stats descriptions are generic. 'List the indexed files and language breakdown' and 'Index statistics' do not explain WHEN to call them or what structure they return. Descriptions should guide tool selection.
lens_read parameter 'start' and 'end' are required in schema but handler uses 'start || 1' fallback, creating inconsistency. Schema should reflect actual behavior (start optional, default 1).