This server has severe structural issues. The source code provided is predominantly documentation website code (Docusaurus React pages, curl examples, and Node.js client samples) rather than an actual MCP server implementation. No explicit MCP server registration, initialization, or protocol handlers are visible. Tools appear to be inferred from documentation examples and marketing copy rather than from a live server implementation. Descriptions are present but generic (10-50 chars, well below the 194-char baseline). Parameter schemas are listed but lack proper JSON Schema type definitions and validation constraints. No output schemas are documented. Error handling guidance is absent. The critical issue: the repository appears to be developer documentation for a WhatsApp API service, not an MCP server codebase. Without an actual server implementation visible (no src/server.ts, no tool registration handlers, no protocol compliance layer), scoring must be conservative.

• Create a proper MCP server implementation (currently missing, only documentation exists). Add explicit tool registration handlers in the MCP protocol layer.
• Expand all tool descriptions to 100-250 characters. Include WHAT the tool does, WHEN to use it, and any prerequisites. Example: 'send_whatsapp_message' should be: 'Send a text message via WhatsApp to a recipient. Requires a valid phone number in E.164 format (e.g., +1234567890) and an active WhatsApp session. Use get_whatsapp_status first to verify session availability. Messages are queued asynchronously; check get_whatsapp_outbound_queue_status to confirm delivery.'
• Add proper JSON Schema constraints for all parameters. For session_id: add 'minimum': 1. For trigger_type: add 'enum': ['message_received', 'scheduled', 'webhook_triggered', ...]. For phone: add 'pattern': '^\+[1-9]\d{1,14}$' (E.164 format).
• Document output schemas for every tool. Specify returned fields, types, and include chaining IDs. Example: create_whatsapp_workflow should return {workflow_id: integer, name: string, status: string, created_at: ISO8601_string}.
• Add parameter format constraints in descriptions. Example: 'phone' -> 'Phone number in E.164 format with country code (e.g., +1234567890). Omit spaces, hyphens, or leading zeros.'
• Implement pagination for list tools: add 'offset' (default: 0) and 'limit' (default: 20, max: 100) parameters. Document total_count and next_offset in return values.
• Add error recovery guidance to tool descriptions. Example: 'If sending fails with 'invalid_phone', ensure the number includes country code and no formatting characters. Use search_contacts to find valid numbers for recipients.'