Single tool 'speak_when_done' has a reasonable description (89 chars, within 10-1024 range) but lacks critical schema documentation. Input parameters (text, voice, speed) are visible in the code but NOT formally registered with JSON Schema in the tool definition. The description is action-oriented but does not explain when to call this vs alternatives, what happens on failure, or retry behavior. No output schema documented. Parameter descriptions exist in code comments but are not exposed to the MCP protocol layer where LLMs can see them. Risk classification (READ_ONLY) is present but error handling guidance is absent.

• Register the tool with explicit JSON Schema: define 'text' as required string (max 500 chars), 'voice' as enum or string with description of available voices, 'speed' as number (0.5 - 2.0 range). Include descriptions for each parameter visible to the LLM.
• Document the output schema: return {"status": "success"|"error", "audio_file": string, "duration_seconds": number, "message": string}. This lets LLMs know what to expect.
• Enhance the tool description to include: (1) When to call it (end of every response), (2) What happens on failure (graceful fallback, no crash), (3) Retry behavior (cached audio reused), (4) Constraints (max text length, supported voices). Target 150 - 250 chars.
• Add error recovery guidance: 'If no audio player is found, the tool returns an error with available players. If the TTS API fails after retries, the tool returns a descriptive error, the agent should inform the user and optionally retry with shorter text.'
• Clarify idempotency: 'Calling this tool twice with the same text and voice will reuse cached audio (same file). This is safe to retry.' This prevents LLM confusion about side effects.

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

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