The 'translate' tool has a basic structure with name, description, and input parameters, but significant gaps in schema documentation and parameter descriptions. The tool definition in cmd/translate-mcp/main.go uses mcp.AddTool() with nil InputSchema and OutputSchema, relying on inference. Input parameters (source, target, text) each have descriptions, but they are generic and lack format constraints (e.g., no enum of valid language codes, no examples of accepted formats). The description itself is minimal (61 chars) and does not explain when to use the tool vs alternatives, what it returns structurally, or error conditions. No output schema is visible in the code. The tool appears to accept free-form language names/codes without validation guidance, inviting hallucinated language codes from LLMs.

• Define and register explicit InputSchema with JSON Schema. List 'source' and 'target' as enum fields containing valid language codes (e.g., ['en', 'ja', 'fr', 'de', ...]) or clearly specify the format (ISO 639-1 codes or full names). Replace example values with a format pattern.
• Expand tool description to 100-200 characters. Example: 'Translate text between languages using Ollama. Supports ISO 639-1 codes (en, ja, fr) or full names (English, Japanese, French). Returns translated text. Use when user requests content in a different language.'
• Add explicit OutputSchema documenting the response structure. Example: {"type": "object", "properties": {"text": {"type": "string", "description": "The translated text"}}, "required": ["text"]}
• Add error handling to the tool description: 'Returns an error if the language pair is not supported, text exceeds 10,000 characters, or the translation service is unavailable. Retry on service errors; verify language codes on validation errors.'
• Update parameter descriptions to remove examples and add constraints: 'source' -> 'ISO 639-1 language code or full language name. Valid codes: en, ja, fr, de, es, zh, ar. (Required, string)'; similarly for 'target'.
• Consider adding an optional 'format' parameter to control output (e.g., plain text vs. markdown) if the backend supports it, with enum constraint.
• Add a 'max_length' parameter documentation or constraint in the description if there is a practical limit on text length accepted by the Ollama model.