Loading ToolBench
A Model Context Protocol server that provides precise code extraction tools using tree-sitter parsing
This server provides 5 code-extraction tools with clear, action-oriented names (get_symbols, get_function, get_class, get_lines, get_signature). Descriptions are present and reasonably detailed, explaining WHAT each tool does and WHEN to use it (e.g., 'USE THIS INSTEAD OF Read() for specific functions'). However, the descriptions contain anti-patterns (emphasized with emojis and formatting that will not render in LLM contexts) and lack structured guidance on parameter constraints. Input schemas are visible and well-formed with proper JSON types (string, integer) and descriptions. Output schemas are not documented in the source code provided, a critical gap for tools that return structured results. Error handling is minimal; there is no guidance on recovery paths when a function is not found or parsing fails. The tool set is well-composed (each does one thing) and names follow verb_noun conventions, which is strong. However, missing output schema documentation and lack of actionable error messages pull the score down significantly.
Extract a complete class definition - USE THIS INSTEAD OF Read() for specific classes! 🎯 **PRECISE EXTRACTION** - Gets exact class boundaries with all methods using tree-sitter. ⚠️ **REPLACES Read() + manual parsing** - No need to read entire files and search manually.
Extract a complete function definition - USE THIS INSTEAD OF Read() for specific functions! 🎯 **PRECISE EXTRACTION** - Gets exact function boundaries with line numbers using tree-sitter. ⚠️ **REPLACES Read() + manual parsing** - No need to read entire files and search manually.
Get specific lines from a file using precise line range control. Use this when you know exact line numbers you need (e.g., from get_symbols output) and want to extract specific code sections without reading the entire file.
Get just the signature/declaration of a function without the full implementation. Use this when you only need to see function interfaces, parameters, and return types for API exploration or documentation.
🚨 **ALWAYS USE THIS FIRST** for code investigation - DO NOT use Read() on code files! List all functions, classes, and other symbols in a file with their line numbers. This is the CORRECT way to explore code structure instead of reading entire files. ⚠️ **REPLACES Read() for code files** - More efficient and structured than reading entire files.
Output schemas are not documented. The code shows tool input parameters but does not explicitly define what each tool returns (e.g., does get_function return line numbers, full source, metadata?). LLMs cannot plan downstream tool chains or extract the right data without knowing output structure.
Descriptions use rendered emoji and markdown formatting (🚨, ⚠️, 🎯, **bold**, etc.) that LLMs will treat as literal text rather than rendering. This makes descriptions harder to parse and wastes tokens. Remove emoji; use plain text formatting.
Error handling and recovery guidance is absent. If a function is not found, a file is binary, or tree-sitter parsing fails, there is no indication of what the LLM should do next. Add error-response guidance: 'Function not found. Check function name spelling and call get_symbols() first.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Parameter constraints are missing or implicit. For example, get_lines accepts start_line and end_line (1-based, inclusive) but does not state maximum range, timeout, or file size limits. This leaves LLMs guessing whether they can request lines 1-1000000.
Tool descriptions reference 'Read()' as a contrast, but Read() is not a tool in this server and the LLM will not understand the comparison. Reframe descriptions around what THIS tool does, not what alternatives are available.