19 tools with complete input schemas and descriptions, but significant quality gaps. Tool naming lacks consistency (buzz_post vs telegram_reply vs telegram_agy_reply creates confusion). Descriptions are adequate (100-200 chars) but lack actionable guidance on when to use each tool vs. alternatives. No output schemas documented. Critical issue: 6 Telegram variants (telegram_*, telegram_codex_*, telegram_agy_*) duplicate functionality with different prefixes, forcing LLMs to reason about which variant to call. Parameters are typed but lack constraints (enums, ranges, patterns). Error handling and recovery guidance absent. No tool annotations (readOnlyHint/destructiveHint). Composition violates single-responsibility: buzz_post conflates channel selection with message posting.

• Consolidate Telegram variants into a single tool set with a 'variant' parameter (codex|agy|default) or separate them into distinct, clearly-named plugins (telegram-codex, telegram-agy). Current naming forces LLM reasoning overhead.
• Document output schemas for all tools. Specify what buzz_post returns (event_id?), what reply returns (message_id?), what buzz_read returns (array of events with which fields?). Include chaining IDs needed by downstream tools.
• Rename generic tools: reply → telegram_reply, react → telegram_react, edit_message → telegram_edit_message, download_attachment → telegram_download_attachment. Prefix all tools with their domain (telegram_, buzz_, dashboard_).
• Add parameter constraints: parse_mode as enum ['Markdown', 'HTML']; emoji as pattern (single Unicode character or shortcode); limit as integer with min/max bounds (1-100); channel as UUID pattern.
• Add error handling guidance to descriptions. E.g., 'If message_id is invalid, call wait_for_message() to retrieve the correct ID. If the channel is not found, call buzz_read() with no channel parameter to list available channels.'