Three tools with complete JSON schemas and basic descriptions. All tools have input schemas with typed parameters and enums where appropriate (formality, gender). However, descriptions are generic and lack actionable context for LLM selection. Parameter descriptions are minimal (e.g., 'Text to translate' without format/length guidance). No output schema documentation. Error handling is present in code but not surfaced in tool definitions. Tool naming follows verb_noun pattern correctly (translate_text, translate_url, proofread). Missing guidance on when to use each tool vs. alternatives, dependency hints, and recovery paths.

• Expand tool descriptions to 100-200 chars. Example: 'Translate text between languages. Use for short strings or multiple texts. Supports formality (formal/informal) and gender preferences. Returns translated text and detected source language.' This guides LLM selection and sets expectations.
• Document parameter constraints in descriptions. Change 'Source language code (minimum 1 character)' to 'Source language code (ISO 639-1, e.g., en, es, fr). Required unless auto-detect is enabled.' Add examples for language codes.
• Add output schema to each tool definition. Example for translate_text: 'Returns {translation: string, detected_language: {iso: string, label: string}}' or document the multiple possible response shapes and when each occurs.
• Clarify text/texts mutual exclusivity in translate_text. Add to description: 'Pass either text (single string) or texts (array of strings), not both. If neither is provided, request will fail.' Consider making one required.
• Add error recovery guidance to tool descriptions. Example: 'On API errors, check that source_lang and target_lang are valid ISO 639-1 codes. If rate-limited, retry after 60 seconds. Contact Kagi support if errors persist.'

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

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