Two tools with basic schemas and descriptions, but significant gaps in parameter documentation, error guidance, and output structure. TTS has 3 parameters with types and descriptions; ASR has 1 parameter. Both descriptions are present but generic (under 200 chars). No output schema documented for either tool. Parameter validation exists in code but not exposed in schema constraints (enums, ranges). Error handling raises exceptions but provides no recovery guidance to LLMs. No tool annotations (readOnlyHint/destructiveHint). Naming is verb-based (tts, asr) but lacks clarity, 'tts' and 'asr' are acronyms, not action verbs like 'synthesize_speech' or 'transcribe_audio'. Output for TTS is TtsOutputResult (path only); ASR returns raw string. Neither tool documents what fields to expect or how to chain results.

• Rename tools to action verbs: 'synthesize_speech' (or 'generate_audio') and 'transcribe_audio' (or 'recognize_speech'). This matches LLM expectations and improves tool discovery.
• Document output schemas explicitly. For TTS, specify: {"audio_path": string, "format": string, "duration_seconds": number}. For ASR, return {"text": string, "confidence": number, "language": string} instead of raw string.
• Add error recovery guidance. Catch ValueError/TimeoutError and return structured errors: {"error": "invalid_speed", "message": "Speed must be > 0", "received": speed}. This enables LLM self-correction.
• Add tool annotations via FastMCP. Mark ASR with readOnlyHint=true; mark TTS with destructiveHint=true. This signals to LLMs which tools are safe to retry.
• Constrain ASR 'content' parameter: add enum or pattern validation. Document supported formats (mp3, wav, flac), max file size, and URL schemes (http, https, file). Add description: 'Absolute file path (e.g. /tmp/audio.mp3) or HTTP(S) URL to audio file. Supported formats: mp3, wav, flac. Max 100MB.'

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

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