This server exposes 10 terminal/file manipulation tools with basic schemas and descriptions. Most tool names follow verb_noun convention appropriately (run_command, set_working_directory, create_file, delete_file, etc.). However, critical gaps exist: (1) descriptions are minimal and lack context about when to use each tool; (2) parameter descriptions are sparse or missing entirely, 'add_newline' lacks a description in the schema; (3) error handling is generic with no recovery guidance; (4) no documentation of output schemas beyond the implied command_result type; (5) no input validation hints or constraints; (6) dangerous operations like 'run_command' and 'delete_file' have no confirmation steps or dry-run modes. The server correctly uses relative paths and maintains a working directory context, which is good composition. However, the overall design lacks production-grade polish, descriptions average ~40 chars (well below the 194-char baseline for A+ tools), and parameter descriptions are almost entirely absent.
Tools (10)
append_to_filewritesource verified55/100
Appends content to a file, optionally adding a newline.
copy_filewritesource verified58/100
Copies a file from source to destination.
create_directorywritesource verified58/100
Creates a directory at the specified path.
create_filewritesource verified58/100
Creates a file with the specified content.
delete_filedestructivesource verified57/100
Deletes a file.
find_filesread onlysource verified63/100
Searches for files matching a pattern using glob syntax.
run_command tool lacks confirmation/dry-run pattern for dangerous irreversible operations. Description does not warn of destructive capability or guide when/how to use safely.
Parameter descriptions are missing or trivial across all tools. Schema shows parameter names but no descriptions for most (e.g., 'add_newline' in append_to_file has no schema description; 'pattern', 'search_path', 'recursive', 'case_sensitive' in find_files lack depth). This violates the pattern requirement that EVERY parameter needs a description.
No output schema documentation. Tools return a command_result object with fields (success, stdout, stderr, returncode, current_directory), but this structure is never formally documented in the tool definition. LLMs cannot plan downstream calls without knowing what fields to expect.
Recommendations
Add detailed descriptions to every tool (150-250 chars each). For 'run_command': 'Execute arbitrary shell commands in the current working directory. Returns stdout, stderr, and exit code. WARNING: Irreversible, use with caution for destructive commands. For exploratory commands, consider read_file or find_files instead.' This tells the LLM what the tool does, when to use it, and risks.
Add descriptions to every parameter in the JSON schema. For append_to_file.add_newline: 'Whether to insert a newline character before appending content (default: true). Set to false if the file already ends with a newline or if you want continuous text.'
Document the output schema. Add a 'Returns' section to each tool docstring: 'Returns: command_result object with fields: success (bool), stdout (str), stderr (str), returncode (int), current_directory (str). Check success=true before using stdout; on failure, stderr contains the error message.'
Add error recovery guidance. In error catch blocks, return specific messages: 'File not found at {file_path}. Current directory: {current_directory}. Try find_files(pattern="*.txt") to locate it.' This guides the LLM's next action.
Implement a confirmation pattern for destructive operations. Add an optional 'confirm=true' parameter to delete_file and document: 'Pass confirm=true only after you have verified the file path. Recommended: call read_file first to preview content before deletion.' Or implement a two-step pattern: delete_file(path, dry_run=true) returns 'File would be deleted: 1.2 MB text file. Call again with dry_run=false to execute.'
Score history
Overall score trend
↑ 14 points across a rubric change (v1 → v2)
45/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
45
2026-07-28+
v2
2026-03-09
F
31
-
v1
58/100
Reads the content of a file.
run_commandirreversiblesource verified52/100
Runs a command in the terminal and returns the result.
Error handling is minimal. Functions catch exceptions generically and return stderr, but provide no recovery guidance. E.g., 'No such file or directory' does not suggest calling find_files() or checking the working directory. Missing the pattern: error responses must tell the LLM what to do next.
Tool descriptions are too short and lack context. Average description length is ~40 chars (e.g., 'Runs a command in the terminal and returns the result.' = 50 chars). Baseline for A+ tools is 194 chars. Descriptions do not explain WHEN to use each tool vs. alternatives, dependencies, or side effects.
No input validation hints or constraints documented. E.g., find_files() 'pattern' param should document glob syntax support, character limits, and examples. Parameters accept unbounded strings with no guidance on valid formats or length limits.
Destructive operations (delete_file, run_command with rm/rm -rf) lack tool annotations or confirmation steps. Modern MCP spec includes destructiveHint to flag high-risk operations, not present here.
delete_filerun_command
Add tool annotations (destructiveHint, readOnlyHint) to the tool metadata. Mark run_command with destructiveHint=true if the command contains 'rm', 'delete', 'DROP TABLE', etc. Mark read_file with readOnlyHint=true. This helps clients warn users before dangerous operations.
Add input constraints to find_files. Document: 'pattern: Glob pattern (e.g., "*.py", "test_*.txt"). Supports *, ?, [abc] wildcard syntax. Max 100 chars. Required. search_path: Directory to start search (default: current working directory). recursive: Search subdirectories (default: false). case_sensitive: Match case in filenames (default: false on Windows, true on Unix).'
Provide bash command alternatives. In run_command description, add: 'For common operations, consider using dedicated tools: read_file (instead of `cat`), create_file (instead of `echo > file`), delete_file (instead of `rm`), copy_file (instead of `cp`). Use run_command only for complex or platform-specific commands.' This prevents redundant tool calls.
Add examples in docstrings (not parameter descriptions). At the bottom of each tool's docstring: 'Example: create_file(file_path="setup.py", content="import sys\nprint(sys.version)\n") creates a file with two lines of Python code.' Examples in descriptions cause LLMs to reuse literal values, keep them in docstrings only.
Document path resolution and limits. In all file tools, note: 'Paths are resolved relative to the current working directory (returned by get_working_directory). Absolute paths (starting with / or C:\) are also accepted. Paths are restricted to prevent directory traversal; attempting ../ outside the session root will fail.' This prevents security confusion.