Loading ToolBench
Server has well-structured tool definitions with clear naming (verb_noun pattern), comprehensive descriptions (150-400 chars each), and complete JSON schemas with type constraints. All 4 tools are properly registered with input schemas and descriptions. However, output schemas are not formally documented, error handling lacks recovery guidance, and parameter descriptions could be more prescriptive about constraints and formats. No tool annotations (readOnlyHint, destructiveHint) present despite all tools being read-only operations.
Gets a contextual snippet of code, typically the containing function or class. The file will be automatically parsed if it hasn't been already. Why use this tool? After finding a specific element (like a function call or declaration), you often need to see the full context in which it exists. This tool allows you to retrieve the entire body of the surrounding function, class, or other block-level element, providing a complete picture for analysis. When to use it: - To examine the implementation of a function you've located. - To understand how a variable is used within its scope. - To review the full definition of a class. Example Scenario: You've used 'list_code_elements_by_kind' to find that a file contains a function named 'calculatePrice'. Now you want to see the actual code of that function. Correct Usage: get_contextual_code_snippets({ path: '/path/to/src/logic.js', row: 42, column: 10 }) This will return the full text of the function or class that contains the code at the specified line and column.
Initializes the Tree-sitter parser and loads language grammars. This is the foundational step for all other code analysis tools and MUST be called once per session before any other tool in this server is used. Why use this tool? You should call this tool at the very beginning of any task that involves reading, understanding, or searching through code. It prepares the server to handle the specific programming languages in the user's project. Without this step, the server cannot parse files, and all other tools will fail. When to use it: - At the start of a new coding task. - When the user wants to analyze code in a language that hasn't been loaded yet. Example Scenario: A user asks you to "find all deprecated function calls in a large codebase containing both Python and TypeScript files." Before you can even start looking at the files, you must prepare the server to understand both languages. Correct Usage: initialize_treesitter_context({ languages: ['python', 'typescript'] }) This command loads the necessary grammars, enabling you to then use other tools on both .py and .ts files.
Output schemas not formally documented. Tool descriptions explain what is returned (JSON arrays, text snippets) but no structured schema definition exists for downstream tool chaining or LLM planning.
Error handling lacks recovery guidance. Handlers throw generic errors ('Unknown tool', 'path and query parameters are required') without suggesting next steps or alternative tools. LLMs cannot self-correct.
Tool annotations missing. All 4 tools are read-only (no state modification), but readOnlyHint is not declared in tool definitions. This prevents clients from optimizing caching and retry logic.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Enumerates all top-level code constructs of a specific type within a file (e.g., all functions, classes, or imports). This provides a high-level 'table of contents' for a file, allowing for rapid understanding of its structure. The file will be automatically parsed if it hasn't been already. Why use this tool? When you are faced with a large, unfamiliar file, reading it from top to bottom is inefficient. This tool gives you an immediate structural overview. It's perfect for getting your bearings, understanding the public API of a module, or quickly finding the major components of a file. When to use it: - As a first step when analyzing a new, complex file. - When the user asks "what functions are in this file?" or "show me all the classes." - To quickly find all API endpoints defined in a route file. Example Scenario: A developer is trying to understand a complex 1000-line 'utils.js' file. Instead of reading it all, they first want to see all the functions it contains to understand what utilities are available. Correct Usage: list_code_elements_by_kind({ path: '/path/to/src/utils.js', node_type: 'function_declaration' }) Response from tool: [ { "name": "formatDate", "start": { "row": 10, "column": 0 }, "end": { "row": 15, "column": 1 } }, { "name": "calculateTax", "start": { "row": 20, "column": 0 }, "end": { "row": 45, "column": 1 } } ] This provides a clean list of all function names and their locations, offering an instant map of the file's capabilities.
Performs a precise, syntax-aware search on a file using a Tree-sitter query. This is vastly superior to text-based search as it understands code structure and avoids false positives. The file will be automatically parsed if it hasn't been already. Why use this tool? This is your most powerful tool for finding specific code patterns. When a user asks to find where a function is called, how a variable is used, or to identify a specific anti-pattern, this tool is the correct choice. It allows you to search for abstract concepts (e.g., "a function call") rather than just text. When to use it: - To find all calls to a specific function. - To locate all instances of a particular class being instantiated. - To identify complex code patterns, like a 'try/except' block that is missing a 'finally' clause. Example Scenario: A developer needs to find all calls to a commonly named function 'execute()'. A simple text search for 'execute(' would return many false positives from comments, variable names, and strings. A structural search is needed for accuracy. Correct Usage: structural_code_search({ path: '/path/to/src/api.js', query: '(call_expression function: (identifier) @func (#eq? @func "execute"))' }) This query specifically finds nodes that are 'call_expression's where the function's identifier is exactly 'execute', yielding zero false positives and providing the exact location of each real call.
Parameter descriptions lack format/constraint details. 'query' parameter in structural_code_search accepts Tree-sitter S-expressions but does not document syntax rules, valid node types, or common patterns. LLMs must guess valid query syntax.
initialize_treesitter_context is a prerequisite for all other tools but this dependency is not enforced or validated. If called out of order, other tools fail silently. No state tracking or validation of initialization.