Loading ToolBench
MCP server for filesystem access with support for reading, writing, searching files, and directory operations
The server provides 16 filesystem tools with mostly complete schemas and descriptions. Naming follows verb_noun convention consistently (read_*, list_*, create_*, delete_, etc.). Descriptions are present for all tools and generally explain purpose and use cases. However, several critical gaps reduce the score: (1) deprecated read_file tool still present alongside read_text_file creates naming ambiguity; (2) parameter descriptions are minimal or missing context about constraints (e.g., regex patterns in grep_content not documented in descriptions); (3) no documented output schemas for any tool, LLMs cannot plan downstream calls without knowing return structure; (4) error handling guidance is absent, tools do not explain what to do on common failures; (5) some tools like edit_file lack documentation of side effects and idempotency guarantees.
Create a new directory at the specified path. Creates parent directories as needed.
Delete a file or empty directory. Cannot delete non-empty directories.
Get a tree view of the directory structure. Shows the hierarchy of files and directories, with optional filtering using glob patterns.
Edit a file by specifying old text to find and new text to replace it with. Supports regex patterns and provides a diff of changes.
Extract and summarize key information from a project directory. Reads README and other documentation files to provide a project overview.
Get detailed information about a file or directory, including size, creation/modification times, and permissions.
Search for text patterns within files using regular expressions. Supports recursive searching, case-insensitive matching, and context extraction.
No documented output schemas for any tool. LLMs cannot infer return structure, field names, or types. Breaks tool chaining (e.g., read_text_file returns what? a string? an object with 'content' field?). Forces agents to guess or add discovery calls.
Deprecated read_file tool coexists with read_text_file. Naming ambiguity forces LLM to choose between two very similar tools. Deprecated marker in description is insufficient, tool should be removed entirely or clearly marked as internal/legacy.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 26 | - | v1 |
List the contents of a directory, including file names, types, and sizes. The results are paginated and can be optionally sorted.
List the contents of a directory with file sizes and optional sorting. Useful for understanding directory structure and file organization.
Move or rename a file or directory. Handles both files and directories.
Read the complete contents of a file as text. DEPRECATED: Use read_text_file instead.
Read an image or audio file. Returns the base64 encoded data and MIME type. Only works within allowed directories.
Read the contents of multiple files at once. This is more efficient than calling read_text_file or read_media_file multiple times when you need to read several files.
Read the complete contents of a file from the file system as text. 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. Use the 'head' parameter to read only the first N lines of a file, or the 'tail' parameter to read only the last N lines of a file. Operates on the file as text regardless of extension. Only works within allowed directories.
Search for files matching a glob pattern within a directory. Uses plocate for fast searching when available, with fallback to glob-based search.
Write text content to a file. Creates the file if it doesn't exist, or replaces the entire contents if it does. Handles encoding transparently.
Error handling guidance absent from all tools. No description of what to do on failure (e.g., read_text_file fails on encoding error, should agent retry? ask user? skip?). No recovery paths documented.
Destructive operations (delete_file, write_file, edit_file) lack confirmation/dry-run capability. Agents can accidentally destroy data. No discussion of idempotency guarantees.
Parameter constraints underspecified. grep_content has 12 parameters but descriptions lack regex dialect, max line limits, default sort order. edit_file doesn't explain if oldText is escaped or raw regex. No validation rules documented.
Pagination support unclear. list_directory mentions results are 'paginated' but no limit, offset, or cursor parameters visible in schema. Without documented pagination, large directories may return unbounded results.