Four tools with complete schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. Tool naming is clear and action-oriented (text_to_speech, list_voices, get_model_status). Descriptions are present but brief (10-50 chars for some). Critical issue: no output schemas documented for any tool, LLMs cannot plan downstream calls or extract structured data. Parameters lack descriptions for optional fields (voice parameter in both TTS tools has no guidance on valid values or defaults). Error handling is minimal, no recovery guidance or actionable error messages visible in tool definitions.

• Document output schemas for all tools. E.g., text_to_speech should return {success: boolean, audioPath?: string, duration?: number, error?: string}. list_voices should return {voices: string[], count: number}. get_model_status already returns structured status in code, expose that schema in the tool definition.
• Add descriptions to the 'voice' parameter: 'The voice to use for speech synthesis. Call list_voices to see available options. Defaults to af_bella if omitted.' This guides LLMs to discover valid values.
• Expand tool descriptions to 100-200 chars. E.g., 'Convert text to speech and play it through system audio. Use this for immediate audio feedback. For batch synthesis without playback, use text_to_speech_with_options.' This clarifies intent and selection criteria.
• Add error handling guidance to descriptions: 'If the model fails to initialize, call get_model_status to check initialization progress and error details. Retry after a delay if status is initializing.' This teaches LLMs recovery paths.
• Consider consolidating text_to_speech and text_to_speech_with_options into a single tool with optional speed parameter (defaults to 1.1). This reduces cognitive load and eliminates redundancy.