Loading ToolBench
MCP server for filesystem readonly access
Six well-named, read-only filesystem tools with clear descriptions (avg 180 chars) and complete JSON schemas. All tools start with action verbs (read_, list_, search_, get_). Schemas include proper type definitions and required fields. However, parameter descriptions are minimal (many under 50 chars), output schemas are not documented, and error handling lacks recovery guidance. No tool annotations (readOnlyHint, etc.) despite all being read-only. Composition is sound, each tool has one responsibility and tools chain naturally (e.g., list_directory → read_file). Security is strong: path validation prevents traversal, symlink checks included, no secrets exposed.
Get a recursive tree view of files and directories as a JSON structure. Each entry includes 'name', 'type' (file/directory), and 'children' for directories. Files have no children array, while directories always have a children array (which may be empty). The output is formatted with 2-space indentation for readability. Only works within allowed directories.
Get detailed metadata about a file or directory including size, creation/modification dates, permissions, and type. Useful for understanding file properties without reading the entire contents. Only works within allowed directories.
Get a detailed listing of all files and directories in a specified path. Results clearly distinguish between files and directories with [FILE] and [DIR] prefixes. This tool is essential for understanding directory structure and finding specific files within a directory. Only works within allowed directories.
Read the contents of a file from the file system. You can specify optional from and to parameters to read a specific range of lines. If these are not provided, the complete file contents are returned. Handles various text encodings and provides detailed error messages if the file cannot be read. Use this tool when you need to examine the contents of a single file. Only works within allowed directories.
Output schemas not documented. LLMs cannot plan downstream calls or extract fields without knowing response structure (e.g., does list_directory return an array of objects with 'name'/'type' fields, or a flat list?). Baseline: 100% of A+ tools document return types.
Parameter descriptions are sparse. 'path' appears in all tools with identical 1-line descriptions; 'from'/'to' in read_file lack format guidance (are these 1-indexed or 0-indexed? inclusive or exclusive?). Baseline: 100% of A+ tools have param descriptions averaging 72 chars.
No tool annotations despite all tools being read-only. MCP spec supports readOnlyHint to signal safety to agents. This would improve agent confidence in tool selection and enable safe auto-retry patterns.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Read the contents of multiple files simultaneously. This is more efficient than reading files one by one when you need to analyze or compare multiple files. Each file's content is returned with its path as a reference. Failed reads for individual files won't stop the entire operation. Only works within allowed directories.
Recursively search for files and directories matching a pattern. Searches through all subdirectories from the starting path. The search is case-insensitive and matches partial names. Returns full paths to all matching items. Great for finding files when you don't know their exact location. Only works within allowed directories.
Error handling lacks recovery guidance. Code throws generic 'Access denied' and 'Parent directory does not exist' errors without suggesting next steps (e.g., 'Try search_files() to locate the file' or 'Allowed directories: /home/user/docs'). Baseline: A+ tools include recovery hints.
search_files excludePatterns parameter lacks clear format guidance. Description says 'glob patterns' but does not explain syntax (e.g., does '*.log' match 'debug.log' or only in root? does '**/*.log' work?). LLMs will guess and fail.