halobot has 9 tools with clear verb-noun naming (list_*, send_*, get_*, start_*, halo_*). All tools have descriptions (avg ~120 chars, within baseline 34-392). Input schemas are present with type definitions and parameter descriptions. However, output schemas are completely undocumented, no tool specifies what fields it returns, forcing LLMs to infer structure. Error handling is minimal; no recovery guidance or actionable error messages. The halo_* tools form a coherent human-in-the-loop pattern but lack idempotency guarantees and confirmation steps for destructive operations (send_message, start_thread). Parameter descriptions are adequate but lack format constraints (e.g., no regex for IDs, no min/max for timeout_seconds). Missing: pagination for list_channels/list_guilds, batch operations, and field-level output documentation.

• Document output schemas for all 9 tools. Specify field names, types, and whether results are paginated. Example: 'Returns {guilds: [{id: string, name: string, member_count: integer}], total: integer}'.
• Add pagination to list_guilds and list_channels: accept limit (1-100, default 20) and cursor parameters; return total_count and next_cursor in response.
• Add format constraints to ID parameters in descriptions: 'Discord snowflake ID (18-20 digit string)' or similar. Add min/max to timeout_seconds: 'Timeout in seconds (1-3600, default 300)'.
• Document error scenarios and recovery paths for each tool. E.g., send_message: 'May fail if channel is archived (try halo_start instead), bot lacks permissions (ask user to grant Send Messages), or message exceeds MAX_MESSAGE_LENGTH (auto-chunked, but may fail if chunks exceed limit).'
• Add idempotency guarantees and optional dry-run support to send_message, send_thread_message, and halo_send. E.g., 'Idempotent: same content sent twice to same channel within 5 seconds returns the same message_id.' Or add a dry_run parameter to preview without sending.