This server has 15 tools with basic schemas and descriptions, but exhibits widespread critical gaps. Tool names are verb-forward and generally clear (read_file, write_file, list_directory, execute_command, etc.), which is good. However, descriptions are extremely terse (10-30 chars, well below the 50-200 char baseline for LLM optimization), parameter descriptions are sparse or absent, output schemas are not documented, and error handling is minimal. The file operations (read_file, write_file, list_directory, create_directory, delete_file, search_files, get_file_stats, move_file) are basic filesystem utilities with adequate naming but insufficient context for LLM decision-making. The n8n tools (n8n_list_workflows, n8n_get_workflow, n8n_activate_workflow, n8n_deactivate_workflow, n8n_execute_workflow, n8n_list_executions) lack documentation on when to use each, what they return, and how they chain. Critically, the execute_command tool (IRREVERSIBLE risk) has no dry-run, confirmation, or recovery pattern, a major security and composability gap. API key handling as optional parameters violates secret-injection patterns. No output schemas are visible. This server would require significant hardening before production use.
Tools (15)
create_directorywritesource verified55/100
Create a new directory (and parent directories if needed)
delete_filedestructivesource verified55/100
Delete a file or directory
execute_commandirreversiblesource verified50/100
Execute a shell command (PowerShell on Windows)
get_file_statsread onlysource verified55/100
Get detailed information about a file or directory
Descriptions are severely under-optimized for LLM decision-making. Most descriptions are 15-30 characters; baseline is 50-200 chars. E.g., 'List all files and directories in a given path' is adequate but lacks WHEN to use (vs search_files), WHAT structure is returned, and any prerequisites.
execute_command accepts arbitrary shell/PowerShell input with IRREVERSIBLE risk but has no dry-run, confirmation step, or recovery guidance. An LLM can invoke 'rm -rf /' without safeguards. This violates the confirmation-request and error-classification patterns.
execute_command
Recommendations
Expand ALL tool descriptions to 50-200 characters, answering: WHAT does this tool do? WHEN should the LLM use it vs similar tools (e.g., list_directory vs search_files)? WHAT does it return? Example: 'read_file: Read and return the complete contents of a single file. Use when you need the full text; use search_files to find files by name/pattern first. Returns the raw file content as a string.'
Add detailed parameter descriptions to every input. For 'path', specify: 'Absolute or relative filesystem path. Max 4096 chars. No symbolic links or relative traversals (e.g., ../). Expanded on invocation.' For 'cwd', explain: 'Working directory for relative path resolution. Defaults to server root. Used in search_files and execute_command to control where patterns are anchored.'
Document output schemas explicitly. For list_directory, specify: 'Returns {"items": [{"name": string, "type": "file"|"dir", "size": number, "mtime": ISO8601_string}], "total": number}. Ordered by name, not paginated; cap 100 items.' This enables LLMs to plan downstream calls.
Implement pagination for list_* and search_* tools. Add 'limit' (1-100, default 20) and 'offset' or 'cursor' parameters. Return 'hasMore: bool' and 'nextCursor: string' to enable efficient iteration without context explosion.
Remove API keys from tool parameters. Move n8n apiKey to environment variable (N8N_API_KEY) or secure config. Tools should reference server-side secrets, never expose them in schemas.
Add confirmation/dry-run step to execute_command. Option 1: add a 'dryRun: bool' parameter that returns the parsed command without execution. Option 2: require confirmation via a separate confirm_command_execution tool. This prevents catastrophic agent mistakes.
API keys exposed as optional tool parameters (apiKey in n8n_* tools). Per pattern:secret-injection, credentials must use server-side secret injection via environment variables or vault. Agent traces log all parameters, secrets leak into logs and prompt history.
Output schemas are not documented in any tool. LLMs cannot plan downstream calls or extract needed data without knowing what fields to expect. E.g., does list_directory return an array of file names, full file objects with metadata, or both?
Parameter descriptions are missing or trivial. E.g., 'path' in read_file has description 'Absolute or relative path to the file' but no constraints (length, character restrictions, forbidden patterns). 'cwd' in execute_command and search_files has no description at all in some cases, forcing LLMs to guess purpose.
No error handling or recovery guidance. Tools do not specify whether errors are retryable, what inputs caused them, or what the LLM should do next. E.g., if delete_file fails because the path does not exist, should the LLM retry, check first with list_directory, or fail? No guidance provided.
n8n_execute_workflow has a generic 'data' parameter (type object, no schema). LLMs cannot determine what fields to pass or how the workflow input is structured. This violates constrained-input and param-validation-rules patterns.
No pagination support or result-limit enforcement. list_directory and search_files may return thousands of items, exhausting the context window. Baseline requires pagination (limit, offset/cursor) and a documented cap (20-50 items).
No distinguishing between read-only and destructive operations in tool descriptions. delete_file and move_file modify state but lack language emphasizing irreversibility. Descriptions should say 'Irreversible: once deleted, data cannot be recovered.'
No batch operations. If an LLM needs to delete 10 files, it must make 10 sequential delete_file calls. Baseline recommends batch variants (delete_files accepting an array) to reduce token waste and latency.
delete_fileread_filemove_file
Implement structured error responses. Every tool should catch errors and return {"success": false, "error": "<specific message>", "retryable": bool, "nextSteps": "<guidance>"}. Example: 'File not found at /path/to/file.txt. Retryable: no. Next steps: use list_directory("/path/to") to verify the file exists.'
Constrain free-form parameters. n8n_execute_workflow's 'data' parameter should either accept a documented JSON schema (inferred from n8n API) or be replaced with named, typed parameters. Document: 'data: JSON object matching the n8n workflow input schema. Typical fields: {"input_field_1": string, "input_field_2": number, ...}. Verify field names in n8n_get_workflow first.'
Add result-limit enforcement. In tool descriptions, state: 'Returns max 50 items. Use offset/limit for pagination.' In code, cap results and return 'hasMore: true' when the API returns more than the limit.
Add state-change language to descriptions. 'Irreversible: deletion cannot be undone. Verify file contents and dependencies before calling.' for delete_file. 'Executes immediately; if the workflow modifies external state (sends emails, creates records), the action is committed.' for n8n_execute_workflow.
Batch operations: offer delete_files(paths: string[], recursive: bool) alongside delete_file for N-file deletion in one call. Similarly for move_file (rename multiple) and copy operations if relevant. Reduce sequential call overhead.
Add clear when-to-use guidance in descriptions. E.g., 'search_files: Find files matching a glob pattern (e.g., **/*.js). Use when you don't know exact paths but can describe them. For a single known file, use read_file directly.' vs 'list_directory: Enumerate all items in a directory without filtering. Use to explore structure or when you need all entries.'
Return chaining IDs. If list_directory returns file metadata, include the full path (not just name) so the LLM can immediately pass it to read_file without an extra lookup.
Validate inputs and return actionable errors. E.g., if execute_command receives a destructive command (rm, del, dd), warn: 'Destructive command detected. This will permanently modify the filesystem. Confirm intent or use dryRun=true to preview.' This prevents silent failures and aids debugging.