Loading ToolBench
Super MCP Code Copilot — AI-powered coding agent server with token-optimized file editing, batch reads, diagnostics, and undo support.
Strong foundation with 22 well-named tools, comprehensive descriptions, and clear parameter documentation. All tools have descriptions (10 - 1024 chars baseline met). Most parameters include type and description. However, output schemas are not explicitly documented in the source, and error handling guidance is minimal. Tool composition is excellent (read, batch-read, search variants; undo support). Security gating middleware present but not fully visible in source. Naming follows verb_noun convention consistently (read_file, search_codebase, execute_command). Descriptions include WHEN-to-use guidance (e.g., read_file TOKEN SAVING section). No secrets exposed as parameters. Batch operations (batch_read_files) reduce token waste. Pagination/limits present in search tools (max_results, limit). Risk annotations (READ_ONLY, WRITE, DESTRUCTIVE, REVERSIBLE) aid agent planning.
Analyze a file for syntax errors, structure, and metadata (functions, classes, imports, etc.).
Read multiple files in a single tool call. Returns content for all files. USE THIS WHEN: You need context from several related files at once (e.g., a module and its tests, or a function and its callers). TOKEN SAVING: Reading 5 files in one call instead of 5 separate read_file calls reduces tool call overhead significantly.
Create a new file with initial content. Fails if the file already exists.
Delete a file from the project.
Execute a shell command in the project directory. Only whitelisted commands are allowed.
Find function definitions in the codebase by name.
Output schemas not documented in source. Tools return results but LLMs cannot see expected fields, types, or pagination structure. Breaks downstream tool chaining and forces agents to guess field names.
Error handling guidance missing. Tools declare risk levels (READ_ONLY, WRITE, DESTRUCTIVE) but do not document what errors can occur, how to recover, or what the LLM should do next. E.g., execute_command may timeout or fail, no recovery guidance.
LSP tools (lsp_find_definition, lsp_find_references) lack descriptions explaining when to use them vs non-LSP variants (find_function, find_references). LLMs cannot disambiguate.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | <=2025-11-25 | v2 |
Find all references to a symbol (function, class, variable) in the codebase.
Get diagnostic information (errors, warnings, linting issues) for a file or the entire project.
Get metadata about a file (size, encoding, language, modification time, etc.).
Get a nested tree view of the project structure, useful for understanding the codebase layout.
Retrieve the full input schema for a specific tool. Used for lazy-loading tool schemas when gating is enabled.
Search for lines matching a pattern with context lines, similar to Unix grep.
List files and directories in the project, with optional filtering by glob pattern.
Find the definition of a symbol using Language Server Protocol (LSP).
Find all references to a symbol using Language Server Protocol (LSP).
Modify a file by replacing a specific line range with new content. Preserves edit history for undo.
Read a file from the project. Supports partial reads for token efficiency. USE THIS WHEN: - You need to see file content before editing - You know the approximate line range of interest (use start_line/end_line) TOKEN SAVING: Use start_line and end_line to read only the lines you need. Reading 30 lines instead of 2000 saves massive tokens.
Full-text search across the codebase using SQLite FTS5 index for fast keyword matching.
Search for text patterns in files using regex or literal string matching.
Set or change the project root directory. This configures the sandbox boundary for all file operations.
Undo the last edit to a file by restoring its previous content from the edit history.
Write or overwrite a file with new content. Creates parent directories if needed.
execute_command accepts arbitrary shell commands with only a whitelist gate (not visible in source). No parameter constraints documented (e.g., timeout max=300 is mentioned but not enforced in schema). Injection risk if whitelist is incomplete.
Batch operations (batch_read_files) cap at 10 files but no guidance on what happens if agent requests 11. No per-item error reporting, if 1 of 10 files fails, does the entire call fail or return partial results?