Three tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. Tool names follow verb_noun convention (check_, list_, get_), which is good. However, descriptions are minimal (34-72 chars, below the 194-char baseline), and critical parameter details are missing. Input schemas show types but lack comprehensive descriptions for all parameters. No visible output schema documentation. Error handling and recovery guidance absent. The tools appear to be defined in test files rather than production code, suggesting incomplete integration.

• Document output schemas for all three tools. Specify field names, types, and whether results are paginated. Example: 'Returns {dialogs: [{call_id: string, start_time: ISO8601, duration_ms: number}], total: number, has_more: boolean}'.
• Expand descriptions to 100-200 chars. For rtp_stats: 'Retrieve RTP stream statistics (packet count, jitter, loss rate, MOS score) for a specific call or all active calls. Use this to diagnose audio quality issues. If call_id is omitted, returns aggregated stats across all streams.'
• Add explicit parameter descriptions for limit and offset in list_dialogs. Example: 'limit: Maximum dialogs to return (1-100, default 50). Larger values may timeout. offset: Zero-indexed starting position for pagination.'
• Define error responses with recovery guidance. Example: 'If call_id not found, try list_dialogs() first to discover available call IDs. If no RTP streams exist, the call may have used a non-RTP protocol.'
• Move tool definitions from test files to production code (src/lib.rs or src/tools.rs) and ensure they are registered with the MCP server initialization, not just tested.