Four tools with basic schemas and descriptions, but significant gaps in parameter documentation, output schema clarity, and error handling guidance. Tool names lack action verbs (translate vs translate_code). Descriptions are present but generic (10-50 chars for some params). No enum constraints on language parameters despite known valid values. Output schemas undocumented, LLMs cannot predict response structure. Error handling returns raw strings without recovery guidance. Parameter relationships (source_language auto-detection) underdocumented.

• Add enum constraint to 'target_language' and 'language' parameters: enum: ['python', 'javascript', 'typescript', 'rust', 'go', 'java', 'c', 'cpp', 'csharp', 'ruby', 'php', 'swift', 'kotlin', 'scala', 'r', 'bash', 'powershell', 'sql', 'html', 'css', 'lua', 'perl', 'haskell', 'elixir', 'dart', 'objc', 'assembly', 'cobol', 'fortran', 'matlab', 'julia']. This prevents hallucinated language names.
• Document output schema for each tool. E.g., 'Returns: string containing translated code (or error message if translation failed).' For supported_languages, specify 'Returns: string with newline-separated language list.'
• Enhance error messages with recovery guidance. Instead of '// ERROR: LLM call failed: {e}', return 'LLM service unavailable. Verify OLLAMA_URL environment variable (currently: {OLLAMA_URL}) and that Ollama is running. Retry after service recovers.'
• Rename 'translate_file_tool' to 'translate_file' (remove redundant '_tool' suffix). Rename 'english_to_code' to 'generate_code_from_description' for clarity.
• Add parameter 'auto_detect_source' (boolean, default=true) to translate tool and document: 'If true and source_language is empty, language is inferred from code syntax. If inference fails, returns error with detected candidates.' This makes the behavior explicit.