Loading ToolBench
Token-efficient code reading MCP server for AI coding agents. Exposes symbol-aware code search, BM25 indexing, file reading, and grep functionality over MCP protocol.
pluck exposes 6 tools with reasonable descriptions and mostly complete schemas. However, three tools (symbol, peek, expand) are placeholder implementations with minimal utility. Naming is clear and action-oriented (read, search, grep, symbol, peek, expand). Descriptions are present and actionable (avg ~120 chars), though some parameter descriptions could be more prescriptive about constraints and error cases. Input schemas are well-defined with proper types and descriptions for all parameters. Output schemas are NOT documented, this is a significant gap for LLMs planning downstream tool composition. Error handling is minimal; tools do not provide recovery guidance or categorization. The practical tools (read, search, grep) are solid; the placeholder tools weaken overall quality.
Expand local call chains. Placeholder handler in Phase 1; full implementation in subsequent phases.
Keyword search via ripgrep passthrough. Pattern is literal by default; pass `-e <regex>` via `args` for regex. Supports extra `rg` flags and working directory specification.
Get a symbol's interface and direct callees without paying for the body. Placeholder handler in Phase 1; full implementation in subsequent phases.
File outline (or raw cat parity). Returns byte-equivalent cat output instead of the outline with `raw: true`. Supports inclusive line ranges.
BM25 chunk search with 12% noise floor. Supports hybrid (BM25+semantic) search when embedding encoder is loaded. Returns natural-language or keyword query results.
Symbol lookup by name (optionally path-qualified: `auth/handleLogin`). Placeholder handler in Phase 1; full implementation in subsequent phases.
Three tools (symbol, peek, expand) are explicitly marked as placeholder/Phase 1 implementations. Registering non-functional tools during handshake confuses agents into attempting them, burning tokens on failures and breaking planning.
Output schemas are not documented for any tool. LLMs cannot predict what fields to expect (e.g., does search return 'lines' or 'matched_lines'? Does read return byte offsets?). This forces runtime discovery and breaks tool chaining.
Error handling and recovery guidance are not documented. Tools do not indicate which errors are retryable vs user-fixable. LLMs cannot distinguish between a transient network failure and an actual invalid input.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | <=2025-11-25 | v2 |
pluck.grep parameter 'args' is an array of strings with minimal constraint documentation. LLMs cannot easily predict valid ripgrep flags without exhaustive documentation or examples. Should provide enum-like guidance on common flags.
pluck.search 'compact' parameter lacks explanation of token-cost tradeoff. LLM cannot reason about when to enable it without understanding the lossiness vs benefit.
pluck.read 'lines' parameter description says 'Inclusive line range, e.g. "100-200"' but does not specify: are lines 0-indexed or 1-indexed? What if range exceeds file? Is it an error or silent truncation?