Loading ToolBench
MCP server for AI assistants to navigate, search, and edit large codebases, logs, and data files with semantic code analysis
largefile demonstrates solid foundational quality with well-structured tool definitions, comprehensive descriptions, and proper schema documentation. All 7 tools have clear names starting with action verbs (get_, search_, read_, edit_, revert_, list_), descriptions exceeding 100 characters, and fully typed input schemas. Error handling is present via a decorator pattern with actionable recovery guidance. However, there are notable gaps: output schemas are not formally documented (descriptions mention what is returned but schema structure is not visible in code), some parameter descriptions lack specificity around formats/ranges, and tool composition could be optimized. The server's semantic code analysis capability is strong (Tree-sitter integration, multi-language support), but the tool interface prioritizes power over discoverability.
Edit large files using search/replace with fuzzy matching. Use instead of line-based editing to avoid LLM line number errors. Fuzzy matching handles whitespace and formatting differences automatically. Preview mode (default) shows diff without applying. Creates automatic backup before changes - use revert_edit to undo. Does NOT support regex in replacement - patterns must be literal text (use fuzzy=true for flexibility).
Get file structure, size, and semantic outline for large files (code, logs, data). Use FIRST when working with any file over 1000 lines or when you need to understand file structure. Returns: line count, byte size, binary detection, long line stats, section headings, and suggested search patterns. For code files, uses Tree-sitter to extract functions, classes, and structure. Does NOT return file content - use read_content or search_content for that.
List directory contents with optional recursion and filtering. Returns file/directory entries with sizes and child counts. Supports file pattern matching via include_pattern (glob format). Use for exploring codebase structure before search_content.
Read specific portions of large files efficiently. Use after search_content locates content, or directly with tail/head modes for logs. Modes: 'lines' (read by offset/limit), 'semantic' (complete functions/classes via Tree-sitter), 'tail' (last N lines - ideal for logs), 'head' (first N lines). Does NOT search - use search_content first to find line numbers, then read_content to examine. For files over 500MB, tail/head modes are most efficient.
Output schemas not formally documented in code. Tool descriptions state what is returned (e.g., 'Returns: line count, byte size, binary detection...') but no structured schema definitions are visible for downstream tool composition or LLM parsing.
Parameter constraints lack specificity. 'max_results' specifies min=1, max=100 range (good), but 'context_lines', 'limit', 'offset', 'max_depth' lack explicit numeric bounds in descriptions. For example, read_content 'limit' defaults to 100 but no maximum is stated, unbounded limits could exhaust memory on files with very long lines.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | C | 60 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 53 | - | v1 |
Find the enclosing function or class for a specific line number. Given a file and line number, returns the complete enclosing definition (function, method, class, struct, etc.) containing that line. Use depth=2 to get the parent definition (e.g., the class containing a method). Falls back to a centered context window for unsupported languages or top-level code.
Restore a file to a previous state from automatic backups. Use when edit_content made unwanted changes. Backups are created automatically before each edit. Current state is saved as new backup before reverting (so revert is reversible). Without backup_id, reverts to most recent backup. Returns list of available backups with timestamps.
Search large files for text patterns without loading entire content into memory. Use when finding functions, classes, errors, log entries, or counting occurrences. Supports: fuzzy matching (handles typos/whitespace), regex patterns, case-insensitive search, inverted matching (like grep -v), and count-only mode. Returns ranked matches with line numbers and context (lines truncated to 500 chars). When count_only=True, returns {count, pattern, fuzzy_enabled, regex_enabled, case_sensitive, inverted} instead of the full results structure.
list_directory description is generic (70 chars: 'List directory contents with optional recursion and filtering. Returns file/directory entries with sizes and child counts. Supports file pattern matching via include_pattern (glob format). Use for exploring codebase structure before search_content.'). Does not explain why this tool exists in the context of a large-file navigation server, when to call it vs. get_overview, or its performance characteristics on deeply nested directories.
Error handling is implemented via decorator (handle_tool_errors) with recovery guidance (good), but recovery messages are generic. E.g., 'File access failed: {e}\n\nSuggestion: Check file path and permissions' does not distinguish between ENOENT (file not found) vs. EACCES (permission denied). LLM cannot determine whether to retry or ask user.
Tool composition: read_content accepts a 'pattern' parameter that 'Overrides offset', this introduces implicit parameter relationships not documented in read_content's description. LLM may pass both offset and pattern, leading to confusion about which takes precedence. Should explicitly state mutual exclusivity or precedence rule in parameter descriptions.
edit_content description states 'Does NOT support regex in replacement' but does not explain what pattern matching IS supported in the replacement text. Unclear whether replacements must be literal strings or if fuzzy matching applies to both search and replace.
revert_edit's backup_id parameter is described as coming from 'response' but the response format is not specified. What fields does a backup object contain? What format is backup_id (UUID, timestamp, etc.)? This breaks the chaining pattern.