WhatsApp MCP server has 9 tools with basic descriptions and parameter schemas, but significant gaps in quality. All tools have descriptions (10-200 chars, mostly adequate), and most parameters include type and description fields. However, schemas lack depth: no enums for constrained inputs (e.g., sort_by accepts 'last_active' or 'name' but no enum), no documented output schemas, and error handling is minimal. The send_message tool is destructive but has no confirmation pattern or dry-run option. Parameter descriptions are generic ('Optional search term') rather than actionable. No tool annotations (readOnlyHint/destructiveHint) despite clear read vs. write distinction. Naming is verb-first and clear (search_contacts, list_messages, send_message), following conventions well. Composition is reasonable, tools are single-purpose and chainable (e.g., search_contacts → get_contact_chats). However, output schemas are not documented, forcing LLMs to infer response structure.

• Document output schemas for all tools. Example: search_contacts returns {contacts: [{jid: string, name: string, phone: string}], total: int}. Include field types and nesting.
• Add enum constraints to sort_by parameter: {type: 'string', enum: ['last_active', 'name']}. Replace free-form descriptions with formal constraints.
• Implement confirmation pattern for send_message: add optional 'dry_run' parameter (default false) to preview message without sending. Return {preview: string, confirmed: bool}.
• Add tool annotations: readOnlyHint=true for all get_*/list_*/search_* tools; destructiveHint=true for send_message; idempotentHint=true for read-only tools.
• Enhance parameter descriptions with format and constraint details. E.g., 'sender_phone_number: Phone number in E.164 format (e.g., 14155552671, no + or spaces)' instead of 'Optional phone number'.