Loading ToolBench
A Model Context Protocol server for filesystem operations including reading, writing, editing, searching, and managing files and directories.
This is a well-structured filesystem MCP server with 12 tools covering file, directory, and search operations. Most tools have clear names starting with action verbs (read_, write_, edit_, move_, list_, create_, search_, find_, get_). All 12 tools have descriptions and visible input schemas. However, there are moderate gaps: (1) Output schemas are not documented anywhere in the provided source, we cannot verify what fields are returned by each tool, which is critical for agent chaining. (2) Parameter descriptions exist but are minimal (avg ~50 chars), lacking detail about constraints, formats, and when to use alternatives. (3) Error handling is present in base_tool.rb (file/directory error rescue blocks) but responses are generic strings ('Error: Path not found...') without actionable recovery guidance. (4) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are visible, even though the tools clearly have different risk profiles. (5) The server uses HTTP+SSE transport via vector_mcp, which is current, but there is no evidence of stateless request handling, per-request _meta/logLevel, or MRTR patterns. This is a B-grade server, solid fundamentals, but lacks the depth expected for 80+ scoring.
Create a directory, including parent directories if needed.
Make exact text replacements in a file. Use dryRun=true to preview changes.
Advanced file finder with sorting, filtering, and metadata. Recursively searches directories with powerful filtering options.
Retrieve metadata for multiple files or directories in a single operation. More efficient than multiple get_file_info calls.
Retrieve metadata (size, dates, type, permissions) for a file or directory.
Get server version, runtime information, and configuration details.
List files and directories in a path as a JSON array.
Output schemas are not documented. The source code shows input schemas for all 12 tools, but there is NO evidence of documented return types or response field definitions. This violates the pattern:tool requirement and prevents agents from chaining results to downstream tools.
Parameter descriptions are generic and lack actionable detail. For example, 'dryRun' in edit_file only says 'Preview changes using diff format', no explanation of when to use it or how to interpret the output. 'excludePatterns' in search_files has no examples or format specification. Descriptions should be 50-200 chars and explain WHAT, WHEN, and prerequisites.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 56 | - | v1 |
Move or rename a file or directory. Fails if the destination exists.
Read the complete contents of a single file. Only works within registered roots.
Read the contents of multiple files. Returns content prefixed by path, or an error message per file.
Recursively search for files/directories matching a glob pattern.
Create a new file or overwrite an existing file with content. Use with caution.
Error responses are generic strings without recovery guidance. The handle_file_error and handle_directory_error blocks in base_tool.rb return messages like 'Error: Path not found - ...' without suggesting what the LLM should do next (e.g., 'Try listing the parent directory' or 'Check if the path exists first'). This violates the pattern:recovery-guide requirement.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are visible in the code. These tools clearly have different risk profiles, read_file is READ_ONLY, write_file is WRITE, edit_file is REVERSIBLE, but there is no evidence these annotations are passed to the MCP protocol. Modern servers should declare hints to help clients reason about tool safety.
No pagination support or result limits documented for list_directory and search_files. These tools can return many results, but descriptions do not mention pagination, result limits, or cursor-based continuation. If a directory has 10,000 files, what does list_directory return? This blocks proper integration with agents that operate under context limits.
Parameter relationships are underdocumented. For example, in find_files, 'modified_after' and 'modified_before' have date format examples ('2025-01-01T00:00:00Z') in descriptions, but the schema provides no date validation. Similarly, 'file_types' accepts an array of extensions (e.g. ['txt', 'pdf']), but it is unclear whether extensions should include the dot or not.
Destructive operations lack dry-run or confirmation patterns. write_file and move_file can overwrite or delete files with no safety net. Only edit_file offers dryRun=true for preview. At minimum, all write operations should support a dry-run option, and the descriptions should warn about irreversibility.