Server defines 5 tools with complete JSON schemas and descriptions. Naming follows verb_noun convention (generate_*, edit_*, transcribe_*). Descriptions are present (avg ~120 chars) but lack actionable context for LLM selection. Parameters are typed with enums and constraints, but descriptions are sparse (many params lack explanation of purpose/format). Output schemas are not documented, LLMs cannot predict response structure. Error handling is minimal; no recovery guidance. Security: API keys injected via config (good), but no per-tool permission gates or audit logging.

• Document output schema for each tool. E.g., generate_image should specify: {url: string, width: number, height: number, model: string, created_at: ISO8601}. Include pagination fields (total, next_cursor) if applicable.
• Add descriptions to all parameters. For 'voice' in generate_speech, specify: 'Voice to use (default: alloy). Valid options: alloy, echo, fable, onyx, nova, shimmer.' For 'model', explain when each model is appropriate.
• Enhance tool descriptions with WHEN/WHY context. E.g., 'Use generate_image to create new images from text. Use edit_image to modify existing images. Both use OpenAI-compatible APIs (OpenAI, Azure, local Ollama).'
• Implement error recovery guidance in handlers. Catch API errors and return structured responses: {error: string, code: string, retryable: boolean, nextSteps: string}. E.g., 'Rate limited. Retry after 60 seconds.'
• Add dry-run or confirmation pattern for write operations. E.g., generate_image could accept a 'dry_run' param to validate prompt without consuming credits, or require explicit 'confirm: true' for high-cost models.