Three tools with complete schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. Tool names follow verb_noun convention (translate_*, health_check). Descriptions are adequate (100-200 chars) but lack actionable guidance on when to use each tool vs. the other. Parameters lack type constraints (e.g., sample_rate has no min/max bounds). Output schemas are not formally documented, responses are JSON strings, not structured objects. Error handling returns plain text rather than categorized, actionable guidance. No tool annotations (readOnlyHint, destructiveHint, idempotentHint). translate_file performs file I/O with side effects (writes, plays audio) but description does not explicitly state this is destructive/irreversible.

• Add formal output schema documentation to each tool. Define return type as structured object with typed fields (e.g., { original_text: string, detected_language: 'en'|'zh', translated_text: string, target_language: 'en'|'zh', audio_base64: string }) instead of JSON-in-text.
• Add numeric constraints to sample_rate: min 8000, max 48000, default 16000. Add format validation to file_path: must be absolute, must end in .wav, must exist and be readable.
• Add tool annotations: translate_file with destructiveHint=true (writes file, plays audio); translate_speech with readOnlyHint=true; health_check with readOnlyHint=true.
• Enhance error responses with categorization and recovery guidance. E.g., 'Translation failed: No speech detected in audio (retryable). Try: (1) check audio quality, (2) increase duration, (3) use translate_file with a WAV file instead.'
• Add explicit description to translate_file stating: 'WARNING: This tool writes a new file to disk and plays audio. It is not idempotent, repeated calls with the same input will overwrite the output file.' Consider adding a dry_run parameter.