A monorepo containing MCP servers for filesystem operations and tool definition optimization. Includes a tool orchestrator that uses LLMs to optimize tool definitions for different AI providers (OpenAI, Anthropic, Google).
This MCP server exposes 12 filesystem tools with reasonable descriptions and clear parameter schemas. Most tools follow the verb_noun naming convention (read_file, write_file, etc.) and have descriptions in the 100-300 character range, which is appropriate. However, there are significant gaps: (1) parameters lack detailed descriptions and constraints in most tools; (2) output schemas are not documented for any tool; (3) error handling guidance is missing; (4) several tools combine multiple operations (e.g., interact_with_file_system is overly generic); (5) no tool annotations (readOnlyHint, destructiveHint) are present despite clear risk classifications. Tool descriptions are present and adequately explain the purpose, but they do not include guidance on constraints, prerequisites, or error recovery. Parameter schemas are structurally sound (proper JSON Schema with types), but lack per-parameter descriptions in the visible code. The tool set is well-composed for filesystem operations, but the definition quality falls short of production grade due to missing parameter documentation and output schema specification.
Create a new directory or ensure a directory exists. Can create multiple nested directories in one operation. If the directory already exists, this operation will succeed silently. Perfect for setting up directory structures for projects or ensuring required paths exist. Only works within allowed directories.
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.
Make line-based edits to a text file. Each edit replaces exact line sequences with new content. Returns a git-style diff showing the changes made. Only works within allowed directories.
Retrieve detailed metadata about a file or directory. Returns comprehensive information including size, creation time, last modified time, permissions, and type. This tool is perfect for understanding file characteristics without reading the actual content. Only works within allowed directories.
Interact with the file system. Supports reading, writing, and editing files; creating, moving, and listing directories; retrieving file information; searching files and directories; and listing allowed directories.
Parameter descriptions are missing or minimal. Input schemas define types (string, array, object) but lack per-parameter descriptions explaining constraints, allowed values, or expected formats. For example, 'path' appears in 10 tools but has no description explaining path format, allowed characters, or symlink behavior.
Output schemas are not documented. None of the 12 tools include descriptions of what fields their responses contain, their types, or how downstream tools can chain the output. For example, search_files returns 'full paths' but the structure (array of strings? array of objects with path + metadata?) is undefined.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Returns the list of directories that this server is allowed to access. Use this to understand which directories are available before trying to access files.
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.
Move or rename files and directories. Can move files between directories and rename them in a single operation. If the destination exists, the operation will fail. Works across different directories and can be used for simple renaming within the same directory. Both source and destination must be within allowed directories.
Read the complete contents of a file from the file system. 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.
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 searches within allowed directories.
Create a new file or completely overwrite an existing file with new content. Use with caution as it will overwrite existing files without warning. Handles text content with proper encoding. Only works within allowed directories.
Tool 'interact_with_file_system' violates single responsibility. It accepts a generic 'operation' string parameter and claims to support 'reading, writing, editing, creating, moving, listing, and searching'. This is a catch-all that forces LLMs to guess the operation string format. It should be split into specialized tools or removed entirely in favor of the domain-specific tools already present.
No tool annotations present. Tools are classified with risk levels (READ_ONLY, WRITE, REVERSIBLE, DESTRUCTIVE) but this metadata is not reflected in the tool definitions via readOnlyHint, destructiveHint, or idempotentHint. LLMs cannot infer which tools are safe to retry or have side effects.
Error handling lacks actionable guidance. Descriptions mention 'detailed error messages' and 'handles errors' but no tool specifies what errors are possible, how to recover, or what the LLM should do next. For example, read_file may fail if the path is outside allowed directories, but the description does not explain this constraint.
Mutual parameter constraints are not documented. For edit_file, the 'edits' array contains 'oldText' and 'newText', but there is no description of what happens if oldText appears multiple times, or if oldText is not found. This ambiguity forces LLMs to guess.
search_files has an 'excludePatterns' parameter with a default of empty array, but the pattern matching rules (case-insensitive? glob syntax? regex?) are not specified. LLMs cannot reliably construct exclude patterns without knowing the syntax.
No pagination support for tools that return lists. list_directory and directory_tree may return large result sets, but neither tool accepts limit or offset parameters. Returning thousands of files could exhaust the context window.
Destructive operations (write_file, edit_file, move_file) lack dry-run or confirmation mechanisms. An LLM can accidentally overwrite critical files. write_file description says 'will overwrite existing files without warning' but offers no dryRun parameter.