Single tool 'text_translate' has a well-structured schema with proper types and descriptions for all parameters. Tool description is comprehensive (194 chars) and explains use cases and constraints. However, output schema is not documented in the source code, the tool returns a complex object with translatedText, detectedLanguage, confidence, from, to, and charCount, but this structure is not formally declared in the tool definition. Parameter descriptions are clear and include constraints (max 5000 chars, language code format). No error handling guidance is present, the tool will throw on API failures but provides no recovery hints to the LLM. The tool name 'text_translate' is clear and verb-based, following naming conventions.

• Add formal output schema to tool definition: {type: 'object', properties: {translatedText: {type: 'string'}, detectedLanguage: {type: 'string'}, confidence: {type: 'number', minimum: 0, maximum: 1}, from: {type: 'string'}, to: {type: 'string'}, charCount: {type: 'integer'}}}
• Replace free-form 'from' and 'to' parameters with enum constraints listing supported language codes (en, fr, de, es, it, pt, zh, ja, ko, ar, etc.)
• Add error handling with recovery hints: 'MyMemory API unavailable. Retry in 30s or use a different translation service.' Include HTTP status codes and actionable guidance.
• Document timeout behavior and rate limits in tool description. Specify max request frequency and timeout duration (e.g., '30s timeout per request, max 10 requests/minute').
• Add per-parameter validation: reject text > 5000 chars with clear error message before calling API. Return 'Text exceeds 5000 character limit. Truncate or split into multiple requests.'

Inferred effective spec: 2025-06-18+.

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