Single tool 'translate' has critical definition gaps. Tool name lacks action verb clarity (should be 'translate_locale_files'). Description is present but generic (58 chars, below 100-char minimum for clarity). Input schema exists but is severely underdeveloped: single 'input' string parameter with minimal description ('Path to the input file or directory'). No output schema documented. No parameter constraints, enums, or format guidance. No error handling guidance. Tool performs file I/O with LLM integration but lacks security warnings about API key exposure in code. Naming is acceptable but description and schema are well below production baseline (avg tool description 194 chars, avg params 4 with full descriptions).

• Expand tool description to 150-250 chars: explain what locale files are supported (JSON, JS, YAML?), which languages are available, what the output directory structure looks like, and when to use this tool vs manual translation.
• Add explicit input schema with: language enum (en-US, zh-CN, zh-HK, etc.), input_path with regex pattern validation, optional output_path, optional model_config object. Each parameter needs a description explaining format and constraints.
• Document output schema: return object with fields {success: boolean, message: string, output_path: string, file_count: number, errors: [{file: string, reason: string}]}. This enables LLM to extract results and plan next steps.
• Move API key to environment variable (DEEPSEEK_API_KEY) or secure vault. Remove hardcoded credentials from source. Accept optional model_config parameter for overrides, but never expose secrets as tool parameters.
• Implement error classification: distinguish 'file_not_found' (user-fixable: check path), 'invalid_language' (user-fixable: list available languages), 'api_error' (retryable: exponential backoff), 'permission_denied' (fatal: check file permissions). Return actionable error messages with recovery hints.