This server has critical definition quality gaps. Tool descriptions are vague and lack actionable context (e.g., 'using the tree command' instead of explaining when/why to call it). Parameter descriptions are minimal, 'file path to show' doesn't specify format, encoding, or size limits. No output schemas are documented, forcing LLMs to guess response structure. Error handling is generic ('Error: <err>') with no recovery guidance. The write-file tool has a dangerous shell injection vulnerability (unescaped content in echo command). No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. Naming is acceptable but descriptions fall well below the 194-char baseline for production tools.

• Expand tool descriptions to 150 - 250 chars. Example for read-file: 'Read the contents of a file. Use this to inspect code, config, or text files before editing. Returns file content as plain text. Fails if file does not exist or is not readable.'
• Add parameter descriptions explaining format and constraints. Example: 'file: Relative path to file (string, max 1024 chars, no absolute paths). Resolved relative to the root directory passed at startup.'
• Document output schemas in tool descriptions. Example: 'Returns {content: [{ type: "text", text: string }]}. For tree-files, text contains newline-separated file paths.'
• Fix shell injection in write-file: use execFile with args array instead of string interpolation. Example: `execFile('tee', [absolutePath], { input: content })`.
• Add tool annotations: readOnlyHint: true for tree-files and read-file; destructiveHint: true for write-file and move-file. This enables agents to reason about safety.