Three tools with complete input schemas and descriptions. Naming follows verb_noun pattern (iter_*, send_*). Descriptions are adequate (40-80 chars) but lack context on when to use each tool or what happens on error. Parameters are well-typed with enums for peer types and filter values. Output schemas are documented via Zod but not exposed in tool definitions, LLMs cannot see what fields to expect. Error handling uses toolError() utility but provides no recovery guidance. Missing: output schema documentation in tool registration, parameter constraints (e.g., limit bounds), and idempotency hints for send_text.

• Add output schema documentation to each tool registration. Include field names, types, and descriptions. Example: iter_dialogs returns {dialogs: [{peer: {id, type}, displayName, unreadCount, ...}], total: number}.
• Add bounds to numeric parameters: limit (1-100), offset (0+), minId/maxId (positive integers), minDate/maxDate (ISO 8601 strings). Document in parameter descriptions.
• Enhance error messages with recovery guidance. Example: 'Invalid peer type. Must be one of: user, chat, channel. Try iter_dialogs() first to discover valid peers.'
• Add toolAnnotations to send_text: mark as destructiveHint=true (sends messages, not idempotent by default). Consider supporting a dry_run parameter or confirmation flow.
• Expand tool descriptions to 80-150 chars with context. Example: 'Iterate over Telegram dialogs (conversations). Returns list of chats, channels, and users with unread counts. Use this to discover available conversations before calling iter_messages.'