Loading ToolBench
MCP server to bridge local documentation context to LLMs
Context Bridge exposes three tools for document discovery and extraction. All three tools are explicitly registered with names, descriptions, and Zod-based input schemas visible in src/index.ts. However, the implementation has significant gaps in description quality, parameter documentation, output schema clarity, and error handling guidance. Descriptions are terse (10-37 chars), parameter descriptions lack detail about constraints and formats, and there is no documented output schema or error recovery guidance. The tools themselves are well-named (verb-noun pattern) and the code is clean, but Definition Quality rubric emphasizes LLM-friendly descriptions and comprehensive parameter documentation, both areas are weak here.
List supported documents in a directory
Extract text from a file
Search text within documents
Tool descriptions are below 20 characters and provide minimal context for LLM selection. 'List supported documents in a directory' (36 chars) is acceptable but terse; 'Extract text from a file' (24 chars) barely meets minimum; 'Search text within documents' (27 chars) is minimal. None explain WHEN to call the tool vs alternatives, prerequisites, or return structure.
Parameter descriptions lack format constraints and validation rules. 'path' is described only as 'Absolute path' with no guidance on validation, edge cases (symlinks, missing dirs), or security (path traversal checks). 'query' in search_documents is just 'Term', no guidance on case sensitivity, regex support, min length, or max length.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
Output schemas are not documented. Tools return JSON-serialized content but the rubric requires documented return types and structure. list_documents returns Info[] (name, path, size, extension, modified) but this is not declared in the tool definition. read_document may truncate and return a warning flag, but this behavior is not advertised. search_documents returns Result[] with 'path' and 'hits' fields, undocumented. Per pattern:tool, 'Document the output schema. LLMs need to know what fields to expect.' 100% of A+ tools have documented return types.
No error handling guidance. Code throws generic errors (e.g., 'Unsupported: .xyz', 'Failed to parse PDF: ...') without recovery suggestions. Per pattern:recovery-guide, errors must tell the LLM what to do next. Current approach: if read_document is called on an unsupported file type, the error is thrown but the tool definition offers no guidance for retrying or calling an alternative. LLMs cannot infer recovery.
read_document silently truncates content to 50KB without structured error reporting. The flag 'truncated' is returned in the response but not highlighted in the tool description. If an LLM reads a large PDF, it will receive a truncated result without warning in the tool contract. Per pattern:response-shaper, return structured objects with clear semantics. A truncation flag buried in JSON is not a recovery hint.
Recursive flag naming is ambiguous. Both list_documents and search_documents expose a 'recursive' boolean with minimal description. 'Recurse' is unclear, recurse into what? Subdirectories? Symlink chains? Does it follow .git or node_modules (which are ignored in glob config)? Per naming rubric, parameter names should be specific. Consider 'recurse_subdirectories' or document behavior explicitly.
No pagination or result limit documentation. list_documents and search_documents may return large result sets. If a directory contains thousands of documents, the tool returns all of them. Per pattern:paginated-result and mxe:enforce-result-limits, tools should accept limit/offset and cap results. Current code does not implement pagination.
Path validation is minimal. src/utils/pathValidator is imported but not shown; normalizePath() may or may not sanitize against path traversal. Per pattern:tool-gateway, 'Treat all agent-provided input as untrusted. Sanitize against [...] path traversal.' Without seeing the validator, cannot verify this is secure. If it only normalizes slashes, it is insufficient.