The server provides 5 tools with clear verb-noun naming (get_*, send_, count_, download_). Tool descriptions are present and adequate (76-124 chars), exceeding the 10-char minimum but below the 194-char production baseline. Input schemas are visible and include type definitions and descriptions for all parameters. However, output schemas are undocumented, tools return free-form strings rather than structured objects, forcing LLMs to parse unstructured text. Error handling is minimal (only basic 'not found' checks in download_voice_message). The server lacks pagination support, result limits enforcement, and per-parameter constraint validation (enums, ranges). get_messages and get_chats lack explicit limit documentation in descriptions, risking large unvalidated result sets. No tool annotations (readOnlyHint/destructiveHint) despite clear risk distinctions between read (get_chats, get_messages, count_user_messages) and write (send_message, download_voice_message) operations.

• Convert all tool responses from unstructured strings to structured JSON objects. Example: get_chats should return {dialogs: [{name, id, type, unread_count}], total: N} instead of a formatted string.
• Add output schema documentation for each tool describing field names, types, and optional fields. E.g., get_messages returns list of {date, id, sender_name, text, is_media}.
• Add explicit range constraints to limit parameters: 'limit: 1 - 100 (default 20)' in parameter descriptions and validate against these bounds server-side.
• Implement per-item error reporting for tools that process collections. If one message fails to download, return success/failure array instead of stopping on first error.
• Add tool annotations via FastMCP decorator to mark send_message and download_voice_message as destructive, and read-only tools with readOnlyHint.
• Enhance error messages with recovery hints. E.g., 'Message 123 not found. Call get_messages(chat_id, limit=50) to retrieve valid message IDs first.'
• Document the dual chat_id format (numeric or @username) more explicitly in all affected parameter descriptions. Consider separate parameters (chat_id, chat_username) for clarity.
• Return key IDs in structured responses to enable tool chaining. E.g., get_chats response must include entity.id so send_message can consume it directly.