Five tools with basic schemas and minimal descriptions. All tools have input schemas with typed parameters and descriptions, meeting baseline requirements. However, descriptions are uniformly terse (10-30 chars), well below the 50-200 char LLM-optimized range. No output schemas documented. No error handling guidance. No parameter constraints (enums, ranges, patterns). run_command and write_file are high-risk operations with no confirmation/dry-run patterns. Tool names are verb-noun compliant but lack context about when to use each vs alternatives (e.g., search_code vs grep directly in run_command). Missing idempotency guidance for retry scenarios.

• Expand all tool descriptions to 50-200 characters. Include WHAT the tool does, WHEN to use it (vs alternatives), and what it returns. E.g., 'Read a file's full contents as a string. Use for source code, config files, or text. Returns {content, size_bytes, encoding}. Fails if file >10MB or unreadable.'
• Document output schemas for all tools. Define return types as JSON objects with typed fields. E.g., list_directory returns {entries: [{name, type, size, modified}], total_count, next_cursor}.
• Add confirmation/dry-run pattern to run_command and write_file. E.g., add a 'dry_run' boolean parameter; when true, return what would happen without executing. Or require explicit 'confirm=true' for destructive ops.
• Add parameter constraints: run_command should reject commands containing '|', '>', '<', '&&', '||' (or whitelist safe commands). write_file should validate path against traversal (no '..'), enforce size limits (<10MB), and require explicit 'overwrite=true' to replace existing files.
• Add error handling guidance to descriptions. E.g., 'If file not found, returns {error: "not_found", suggestion: "Check path spelling or use list_directory to browse."}' Categorize errors as retryable (network timeout) vs user-fixable (permission denied) vs fatal (disk full).

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry