Server has 4 tools with clear verb-based names (list_, read_, mark_) and reasonable descriptions (100-150 chars). Input schemas are present with typed parameters and descriptions. However, parameter descriptions lack detail on constraints, formats, and error recovery. Output schemas are documented via struct tags but lack explicit documentation in tool definitions. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Error handling is basic, no recovery guidance or actionable error messages visible in handlers.

• Add readOnlyHint and destructiveHint to mcp.Tool definitions. E.g. mark_channel_read should have destructiveHint=true; list_unread_channels should have readOnlyHint=true. This signals safety constraints to LLMs without requiring description parsing.
• Enhance parameter descriptions with explicit constraints. E.g. 'channel: Telegram channel identifier (@username or numeric ID, 1-32 chars for username, 10+ digits for ID)' and 'limit: Maximum messages to return (1-100, default 50)'.
• Implement actionable error messages with recovery hints. E.g. instead of 'channel not found in dialogs', return 'Channel "xyz" not found. Call list_unread_channels() to see available channels.' This guides LLM retry logic.
• Add InputSchema and OutputSchema to mcp.Tool definitions using JSON Schema. Document the structure of listChannelsOutput, readChannelOutput, etc. explicitly so LLMs know what fields to expect without reading handler code.
• Add idempotentHint=true to read_channel_unread (reading does not modify state) and list_unread_channels. This signals to LLMs that these calls are safe to retry without side effects.

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

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