Loading ToolBench
MCP server for visual file tree exploration with preview and symbols
Single tool 'explore_tree' has exceptional parameter schema completeness and descriptions for a file-system tool. The schema is explicit and well-documented in JSON Schema format with 15 parameters, all with descriptions. The tool description is comprehensive (600+ chars) and includes WHEN/WHY guidance ('WHEN TO USE', 'COMMON PATTERNS', 'TOKEN OPTIMIZATION', 'WHEN NOT TO USE'). However, output schema is not formally documented in the source, only preview/formatting is shown. Error handling is minimal (no guidance on recovery or retryable conditions). No tool annotations (readOnlyHint exists via risk field but not in schema). Composition is solid (single responsibility). Security: path traversal and command injection risks in file system access are not explicitly discussed, though input validation appears present in explorer.ts (not fully visible).
Explore directory trees with file previews and optional code symbol extraction. Replaces multiple Glob/Grep/LS/Read calls with a single efficient operation. WHEN TO USE: - Initial codebase exploration ("what's in src/") - Finding files by pattern ("all .tsx components") - Understanding project structure before making changes - Locating functions/classes across files (with show_symbols) COMMON PATTERNS: 1. Quick overview: { path: "/project/src", depth: 2 } 2. Find components: { path: "/project/src", filter: "*.tsx", depth: 3 } 3. Find a function: { path: "/project/src", show_symbols: true, search: "function:handleSubmit" } 4. Shallow scan: { path: "/project", depth: 1 } - just top-level structure TOKEN OPTIMIZATION: - Default settings are optimized for low token output - show_symbols: false by default - enable only when you need function/class names - Use filter to limit to relevant file types (e.g., "*.{ts,tsx}" for TypeScript) - Use depth: 1 for large directories, then drill into specific subdirs - Binary files (.png, .mp3, etc.) are auto-detected and show "[Binary file: .ext]" instead of content WHEN NOT TO USE: - Reading a specific known file → use Read tool - Searching for text content across files → use Grep tool - You already know the exact file path → use Read tool directly
Output schema not formally documented. The tool returns formatted tree/JSON output but the response structure (fields, types, nesting) is not specified in the tool definition. LLMs cannot plan downstream operations or extract structured fields without knowing the response schema.
No error handling guidance. Tool description lacks recovery instructions for common failure modes (invalid path, permission denied, max depth exceeded, file read errors). LLMs receive no actionable next steps on failure.
No tool annotations in schema. 'explore_tree' is read-only and idempotent but lacks readOnlyHint and idempotentHint annotations. The risk field in metadata says 'READ_ONLY' but this is not in the JSON Schema as a formal annotation.
Path traversal input validation not explicit in visible code. The tool accepts a 'path' parameter without explicit validation against '..' or symlink attacks visible in provided source. Security constraint 'pattern' or validation logic should be documented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Result cap not explicitly documented in description. The tool accepts 'max_files' (default 100, max 500) but the impact of hitting this limit (partial results vs error) is not explained. Should clarify: 'Returns up to max_files results; if truncated, result includes truncated=true and total_scanned=N'.