Two tools with reasonable schema coverage and descriptions, but with notable gaps. `compress_universal` has a complex parameter set (7 params) covering both file and batch operations, with input_path documented but several optional parameters lacking clarity on defaults and constraints. `get_image_info` has clearer semantics but detail parameter enum values ('basic'/'full') are only implied in description, not formalized. Both tools have Chinese-language descriptions that are somewhat verbose for LLM consumption (>200 chars, against best practice of 50-200). Schemas are visible and typed, but validation guidance and error recovery paths are underspecified. No output schema documentation found in code excerpts.

• Translate tool descriptions to English and reduce length to 50-200 characters. Example: compress_universal → 'Compress or convert images with optional batch processing, quality control, and dimension constraints.'
• Formalize 'formats' parameter as oneOf: { type: array, type: string }, or offer separate variants (format_list vs format_single).
• Declare 'detail' as enum with values ['basic', 'full'] in schema, not just description.
• Document 'quality' as nullable integer (null | 1-100) or use two separate parameters (auto_quality: boolean, manual_quality: 1-100).
• Add 'OUTPUT_SCHEMA' section in docstrings or inline comments describing return structure: e.g. { success: boolean, output_paths: string[], compression_ratio: float, error?: string }.
• Add default behavior to optional parameters: 'output_path: if omitted, files are written alongside input file with _compressed suffix'.
• Include recovery hints: 'If compression fails due to unsupported format, call get_image_info() first to verify format compatibility.'
• Implement per-item error reporting for batch operations. Instead of 'Batch processing failed', return { successful: [paths], failed: [{path, error}] }.