Single tool 'translate' has a clear verb-noun name and acceptable description (95 chars), but lacks critical depth. Input schema is present with three parameters (text, target_language, source_language), all with type definitions and descriptions. However, output schema is completely undocumented, the tool returns a string but LLMs cannot infer structure or error cases. Parameter descriptions are minimal (10-40 chars) and lack format guidance, constraints, or examples of valid ISO codes. No error handling guidance provided. The tool accepts language names OR ISO codes but does not document the resolution logic or fallback behavior. Missing: output schema documentation, enum constraints for language codes, error recovery guidance, and actionable parameter constraints.

• Document output schema: specify that success returns translated text (string), and errors return error messages. Define what constitutes success vs failure for the LLM.
• Add enum constraint or reference to language-codes resource in parameter descriptions. E.g., 'ISO 639-1 code (e.g., en, es, fr) or language name. Call the language-codes resource to see all supported values.'
• Implement structured error responses: return {"success": false, "error": "<category>", "message": "<actionable guidance>"} instead of plain strings. Categorize as retryable (rate limit, timeout) vs user-fixable (invalid language).
• Add dependency hint to tool description: 'If unsure of language codes, call the language-codes resource first to see supported languages and their ISO codes.'
• Validate language codes before API call and return clear error: 'Invalid language code: got "xyz", must be ISO 639-1 code (e.g., en, es, fr). Call language-codes resource to see all supported values.'

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

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