Loading ToolBench
MCP Server for vector-based semantic code search in Claude Code. Index your codebase locally with LanceDB and search code, files, and symbols using natural language.
vectorgrep demonstrates solid tool design with clear naming, comprehensive descriptions, and well-structured schemas. All 7 tools follow verb_noun conventions (init, search_code, search_files, search_symbols, index_status, reindex, index_update). Descriptions are detailed (100-250 chars) and explain WHAT, WHEN, and prerequisites. Input schemas use proper JSON Schema with types and descriptions for all parameters. However, output schemas are not documented, responses are wrapped in generic text content without specifying the structure agents should expect. Error handling is present but lacks recovery guidance. Tool annotations (readOnlyHint/destructiveHint) are absent despite clear risk classifications (WRITE vs READ_ONLY).
Show whether a project is indexed and its index statistics: files, chunks and symbols, embedding provider and model, and when it was last indexed. Use it to decide whether init or index_update is needed.
Update the index after code changes: re-indexes only files that were added, modified or deleted since the last run. Run it after larger edits or when search results look outdated.
Build the semantic search index for a project. Required once before any search. Scans the project's code files, splits them into symbol-aware chunks, embeds them locally (Ollama, or the built-in transformers.js fallback) and stores them outside the project. Takes seconds to minutes depending on project size. After code changes, use index_update instead of running init again.
Rebuild the index from scratch. The existing index is replaced only once the new one is complete; if embedding fails, it stays unchanged. Only needed after changing embedding settings or when the index seems broken; for normal code changes use index_update, which is much faster.
Find code by describing what it does in natural language, e.g. "where is the fan speed adjusted based on temperature". Prefer this over grep when you don't know the exact function or variable names; use grep for exact text. Returns ranked code chunks with file path, line range and symbol. Optional filters: language, filePattern. Requires an index (run init once).
Output schemas not documented. Tools return generic text content without specifying structure (fields, types, pagination). LLMs cannot plan downstream calls or extract data reliably.
Tool annotations missing. Despite clear risk classifications (init/reindex/index_update are WRITE; search_* are READ_ONLY), no readOnlyHint or destructiveHint annotations present. Agents cannot infer safety properties.
Error handling lacks recovery guidance. No documented error categories (retryable vs user-fixable vs fatal) or actionable next steps. E.g., 'index not found' should suggest 'run init first'.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | <=2025-11-25 | v2 |
Find which files relate to a feature or concept, described in natural language, e.g. "payment processing". Returns file paths ranked by relevance, without code — a good first step to orient yourself before reading files. Requires an index (run init once).
Find functions, classes, methods, interfaces and types by exact or partial name (e.g. "TapoService") or by description. Exact name matches rank first. Returns each definition's location and first lines. Optional filter: symbolTypes. Requires an index (run init once).
Pagination not documented. search_code, search_files, search_symbols accept 'limit' but no offset/cursor or total_count. Large result sets could exhaust context without pagination guidance.
Concurrency conflict handling underdocumented. INSTRUCTIONS mention 'write tools fail if another session runs init/reindex/index_update', but no error message guidance or retry strategy provided.