Loading ToolBench
Secure filesystem MCP server for reading, writing, searching, diffing, and patching files.
The Filesystem MCP server presents a solid foundation with 13 well-structured tools covering file operations, search, and diffing. Tool naming follows verb_noun conventions consistently (create, delete, read, list, etc.), which is strong. However, the definition quality is held back by two critical issues: (1) Tools 'diff' and 'patch' have no visible input schemas or descriptions in the provided source code, only entries in package.json with missing details. (2) Parameter descriptions are minimal (12-45 characters), falling below the 72-char baseline for production tools. Most descriptions lack explicit format guidance, constraint hints, or when-to-use context. Error handling guidance is present but sparse. The server demonstrates awareness of security (PathGuard, sandbox restrictions via allowed roots, destructive/readonly hints via toolAnnotations), but lacks documented permission scopes and recovery guidance in error responses. Resource and prompt support are present but definitions are not visible in the excerpt.
Create a new file with specified content at a given path
Delete a file or directory at the specified path
Generate a unified diff between two files
Edit a file by replacing a section of text
Find files matching glob patterns or criteria
List contents of a directory
List the configured allowed root directories
Move or rename a file or directory
Tools 'diff' and 'patch' lack visible input schemas and descriptions in source code. Listed with file='package.json' instead of src/tools/*.ts, suggesting definitions may be missing or inferred. Per hard scoring rules, both tools scored 0 for schema/description, capping their overall at 28-30. This violates the fundamental requirement that every tool must have both a description and input schema.
Parameter descriptions are uniformly short (12-45 characters), averaging 35 chars against a 72-char baseline. Descriptions lack format guidance, constraint hints, or when-to-use context. Example: 'The path where the file should be created' (45 chars) omits path format rules, character restrictions, or whether relative/absolute paths are allowed. This forces LLMs to guess parameter expectations.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | 2025-11-25+ | v1 |
Apply a unified diff patch to a file
Read the contents of a file
Replace all occurrences of text in a file
Search for text patterns in files within allowed directories
Get file or directory metadata and information
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract structured data without knowing what fields to expect. For example, 'list' should document whether it returns an array of {name, size, type, mtime} objects, what pagination looks like, and whether total counts are provided. This omission makes tool-chaining fragile.
No recovery guidance in error descriptions. If a tool fails due to invalid input, the LLM has no direction on what to try next. Example: 'delete' tool description does not explain what happens if the path doesn't exist, whether the error is retryable, or whether to use 'list' first to verify the path. Error handling guidance is undocumented.
Destructive and write operations (create, delete, edit, move, replace_text, patch) lack confirmation or dry-run patterns. No tool explicitly supports a '--dry-run' mode or requires confirmation before executing irreversible changes. An agent mistake could delete critical files. The toolAnnotations (WRITE, DESTRUCTIVE) are present but insufficient without pre-execution review.
Tool 'stat' uses a generic name that does not convey intent. 'stat' is a Unix command but does not signal 'get file metadata' to LLMs. Consider 'get_file_metadata' or 'get_file_info' for clarity. The name alone requires the LLM to read the description.
Tool descriptions do not explain dependencies between tools. For example, 'edit' uses 'oldText' matching but the description does not suggest calling 'read' first to find the exact text, or 'search_text' to locate patterns. This forces agents to discover the workflow through trial and error.
'list_roots' tool is exposed but lacks context in its description about when users should call it. The description ('List the configured allowed root directories') is 51 chars and does not explain whether this is a discovery tool to be called before path operations or a debugging aid.