Loading ToolBench
A high-performance C++ MCP server for parallel code structure analysis using Tree-sitter. Analyzes C++, Java, Kotlin, and TypeScript source code to extract symbol locations and code structure without SDK dependencies. Uses 10 parallel threads with semaphore-based concurrency control to minimize memory usage by caching only symbol coordinates and source text.
Three tools with adequate descriptions (50-200 chars) but critical schema gaps. All tools lack explicit input parameter descriptions and type constraints. The 'scan' tool accepts a root_path string but provides no validation rules, format constraints, or error guidance. 'get_detail' accepts symbol_paths array but lacks item type documentation. No output schemas are documented. Error handling is absent, no guidance on what happens if a scan fails, a symbol is not found, or a file cannot be read. Tool names follow verb_noun convention (scan, get_summary, get_detail) but descriptions lack WHEN/WHY context for LLM selection.
Retrieves detailed source code for specific symbols by name. Uses cached byte offsets to extract only the requested code sections from memory, enabling millisecond-level detail retrieval without re-parsing.
Returns a summary of all discovered symbols (functions and classes) from the last scan. Provides symbol names, file paths, and line numbers without loading full source code. Designed for fast AI context building to prevent hallucination.
Initiates parallel analysis of source code in a directory tree. Scans all files matching supported language extensions (.cpp, .java, .kt, .ts) using Tree-sitter parsers with configurable thread count. Extracts function and class definitions with their byte offsets, line numbers, and file paths. Results are cached in memory for fast subsequent queries.
Input parameter descriptions missing. 'root_path' in scan has no description; 'symbol_paths' in get_detail lacks item type and format guidance. LLMs cannot infer whether symbol_paths expects 'MyClass::method' or 'MyClass.method' format.
No output schemas documented. Tools return JSON but LLMs have no visibility into response structure (field names, types, nesting). Agents cannot plan downstream operations or extract required IDs.
No error handling or recovery guidance. If scan fails on a directory, get_detail is called on non-existent symbols, or a file cannot be read, tools provide no actionable error messages. LLMs receive raw failures with no next-step guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | 2026-07-28+ | v2 |
Parameter constraints not documented. 'root_path' has no validation rules (absolute vs relative, max length, symlink handling). 'symbol_paths' array has no min/max length or format pattern. LLMs may pass invalid values.
Tool descriptions lack WHEN/WHY context. 'get_summary' says it returns symbols but does not explain when to call it vs get_detail, or that it must follow a scan. Agents cannot reason about tool sequencing.