Loading ToolBench
File explorer with read/write and code intelligence
Server provides 17 clearly-named tools with complete JSON Schema input definitions and brief descriptions. Naming is verb-first and action-oriented, following production conventions. However, descriptions are uniformly short (10 - 50 chars), falling below the production baseline of 194 chars and failing to provide context on WHEN to use each tool, prerequisites, or next steps. Parameter descriptions are present but minimal (5 - 20 chars), omitting format constraints, ranges, and validation rules. Output schemas are not documented, LLMs cannot predict return structure or plan chaining. No error handling guidance. The code shows proper schema registration via tools.XxxSchema() functions, but source files defining those schemas are not provided, limiting verification of field-level documentation. File system tools (write_file, delete_file) lack dry-run or confirmation patterns despite being destructive. LSP/IDE tools (code_goto_definition, code_find_references) require 'path', 'line', 'col' parameters but no schema documentation clarifies whether 'line' and 'col' are 0-indexed or 1-indexed, inviting off-by-one errors.
Get suggested code actions for a file (based on diagnostics)
Get completion candidates at a cursor position
Get parse errors and diagnostics for a file
Find all references to the symbol at a given position across open documents
Return the definition location for a symbol at a given file position
Return hover information (doc comment, type signature) for the symbol at a position
Get import declarations for a file
Descriptions uniformly under 60 characters, averaging ~40 chars, well below production baseline of 194 chars. Lack context on WHEN to use (vs. similar tools), prerequisites (e.g., 'file must be open in LSP store'), and next steps. Example: 'code_goto_definition' is described as 'Return the definition location for a symbol at a given file position' (56 chars) but omits that line/col must be 0-indexed, that the file must exist in the document store, and what to do if no definition exists.
Parameter descriptions are minimal (5 - 20 chars) and lack validation rules, format constraints, and ranges. Example: 'offset' in read_file is described as 'Line number to start reading from (1-based, optional)', good! But 'limit' is just 'Maximum number of lines to return (optional)' with no stated upper bound, inviting LLMs to request millions of lines. 'line' and 'col' in code_goto_definition lack clarity on whether they are 0-indexed or 1-indexed, risking off-by-one errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 60 | - | v1 |
Get the namespace/module structure for a file
List symbols (functions, structs, classes) in a file by opening it in the LSP document store
Search for symbols across all open documents
Delete a file or directory, optionally recursively
Return metadata (size, permissions, MIME type) for a file or directory
Search for files matching a glob pattern within a directory
List directory contents with optional hidden-file and recursive support
Move or rename a file or directory
Read file contents with optional line offset and limit
Write content to a file, optionally creating parent directories
Output schemas are not documented in the source code provided. LLMs cannot predict what fields are returned, their types, or what IDs/references are included for chaining downstream calls. Example: does file_search return a 'matches' array with 'path' and 'size' fields, or 'results' with 'file' objects? Does list_directory return 'items' or 'entries'? This forces LLMs to guess or execute blind.
Destructive tools (write_file, delete_file, move_file) lack dry-run, confirmation, or MRTR (Multi Round-Trip Request) support. An agent can delete_file without preview or user confirmation, risking data loss. No error messages guide recovery ('deleted file XYZ; to restore, check trash or ask the user').
No error handling guidance. Responses do not indicate what the LLM should do next if a file is not found, a path is invalid, or LSP resolution fails. Example: code_goto_definition can fail if the file is not in the document store or the symbol has no definition, but no documented error response tells the agent to open_file first or search_workspace_symbols instead.
LSP tools (code_symbols, code_hover, etc.) require a 'content' parameter in some cases, but the documentation does not explain when it is required vs. optional, or how it interacts with the file being 'open in the LSP document store' (mentioned in code_symbols description). This creates ambiguity: should the agent pass file content, or does the tool read it from the store?
No limit or pagination guidance for list_directory (recursive), file_search, or code_workspace_symbols. An LLM could recursively list a 10,000-file project or request 1M search results. Returning 500 results wastes tokens and degrades reasoning. Descriptions should state 'default limit 50' or 'max results capped at 100'.
write_file and delete_file include a 'create_dirs' and 'recursive' flag respectively, but there is no guidance on what happens if these flags are omitted or false (does the write fail? does the delete silently succeed on an empty dir?). Defaults should be explicitly documented to prevent unexpected behavior.