A Model Context Protocol (MCP) server for platform-agnostic file capabilities, including advanced search and replace, and directory tree traversal
Filesystem server has 10 tools with basic registration but significant quality gaps. Tool names follow verb_noun convention (read_file, write_file, delete_file) which is good. However, source code inspection reveals incomplete schemas and descriptions. Most tool registration files are not shown in detail, making full assessment difficult. Based on visible patterns: descriptions appear present but likely generic; parameter schemas not visible in provided code; no evidence of error handling guidance or output schema documentation. The server handles high-risk operations (delete_file, delete_directory, move_path) without visible confirmation patterns or detailed error recovery guidance.
Input schemas not visible in provided source code. Cannot verify parameter types, constraints, or descriptions for any tool. Rubric requires explicit schema visibility.
Destructive operations (delete_file, delete_directory) lack visible confirmation or dry-run patterns. High-risk tools should support confirmation_request pattern to prevent accidental data loss.
No visible error handling guidance in tool definitions. Error responses should guide LLM on recovery actions (retry, lookup, ask user). Current implementation likely returns raw errors.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 36 | <=2025-11-25 | v2 |
Output schemas not documented. LLMs cannot plan downstream tool calls without knowing what fields are returned. E.g., list_files should document returned fields (name, path, size, type, etc.).
Tool registration files referenced but not shown in detail. Cannot verify actual schema quality.