Five file-manipulation tools with complete JSON schemas and basic descriptions, but critical gaps in parameter documentation and error handling. All tools lack descriptions for individual parameters (e.g., 'path', 'content', 'hunks'). The 'apply_patch_batch' tool has an undocumented 'operations' array with no schema detail. No error recovery guidance, no idempotency markers, and no confirmation pattern for destructive operations. Naming is verb-forward (apply_patch_*) but the batch variant obscures its scope. Output schemas are not documented. These are low-level file tools that would benefit from higher-level composition and clearer safety boundaries.

• Add descriptions to every parameter. For 'path': 'Absolute or relative file path. Must not contain .. or symlinks. Max 4096 chars.' For 'content': 'File content as UTF-8 string. Max 10MB.' For 'hunks': 'Array of edit hunks. Each hunk has context (surrounding lines for validation) and lines array with op (context|add|remove) and text.'
• Document output schemas. E.g., apply_patch_add_file returns {success: bool, path: string, size_bytes: int, checksum: string}. apply_patch_delete_file returns {success: bool, path: string, deleted_at: ISO8601}.
• Add confirmation pattern for destructive operations. apply_patch_delete_file should support a 'dry_run' parameter (default false) that lists what would be deleted without executing. Or require explicit 'confirm: true' parameter.
• Specify constraints in parameter descriptions. E.g., 'path must be within the project root; relative paths are resolved from the workspace root. Absolute paths outside the workspace are rejected.'
• Add error recovery guidance. E.g., 'If path not found, call list_files() to discover available files. If operation fails due to permission, check file ownership and permissions.'