mcp-listen demonstrates strong tool naming, comprehensive parameter descriptions, and explicit input schemas. All three tools are action-verb named and appropriately scoped. Schemas are complete with types and ranges. However, output schemas are not documented in the code, and error handling guidance is not visible in the definitions. Tool descriptions are detailed (100-250 chars), exceeding baselines but appropriately pitched for voice/audio domain complexity. Parameter descriptions are uniformly present and detailed, explaining ranges, defaults, and dependencies clearly.

• Document output schemas for all three tools. For capture_audio: specify that response includes file_path (string), duration_ms (number), sample_rate (number), speech_detected (boolean), silence_reason (string|null). For voice_query: specify response includes transcription (string), response (string), model (string), duration_ms (number). For list_audio_devices: specify array of device objects with properties: id (string), name (string), index (number).
• Add error handling and recovery guidance to each tool description. Example: 'If no devices are found, ensure microphone is connected and system permissions are granted. If capture fails due to missing audio support, verify your Node.js build includes audio codec support.' Similar guidance for voice_query regarding Whisper/Ollama availability.
• Clarify the device parameter behavior: document that passing a numeric index is discouraged because indexes shift when devices are added/removed, and explicitly state that string IDs are stable. Add guidance: 'Always call list_audio_devices first if the agent does not already have a device ID.'
• In voice_query, separate the 'Recording stops automatically when the speaker stops talking' claim from the mechanism description. Clarify: 'stop_on_silence (default true) uses on-device voice activity detection to end recording after silence_ms milliseconds of silence once speech is detected, or after duration_ms maximum, or after 10 seconds if no speech is detected.'
• Add parameter constraints in descriptions: for duration_ms across both tools, explicitly state '100 - 30000 ms'; for silence_ms, state '100 - 10000 ms'. These are present in schema but should be prose-documented as well for LLM visibility.