Server has 10 tools with explicit schemas and descriptions. Naming follows verb_noun convention (get_, send_, search_, etc.). Descriptions are present but vary in quality (50-150 chars, below the 194-char baseline). Schemas include types and descriptions for most parameters. Critical gaps: no output schemas documented, missing error handling guidance, no parameter validation rules stated, and batch operations lack clear approval/risk semantics. Tool composition is reasonable but send_batch_messages conflates multiple concerns (risk assessment + approval + sending).

• Document output schemas for all tools. E.g., get_chats should specify: returns array of {chat_id, participants, last_message_date, message_count}. Include all fields needed for downstream tool calls (e.g., chat_id for get_chat_messages).
• Add min/max bounds to numeric parameters: limit (1 - 100), hours_ago (1 - 8760), and document defaults explicitly (e.g., 'default 20' for limit).
• Split send_batch_messages into three tools: (1) assess_batch_risk(items) → returns risk_level and required_approval; (2) request_approval(risk_assessment) → returns approval_token; (3) send_batch_messages(items, approval_token) → sends only if token valid.
• Add error handling guidance to each tool description. E.g., send_message: 'Returns error if recipient not found, try search_contacts() first. Errors are retryable if service unavailable; non-retryable if invalid phone/email format.'
• Document approval_token generation and validation. Specify valid risk_level enum values, what happens if token is missing/invalid, and how LLMs should request approval before calling send_batch_messages.