Loading ToolBench
MCP server for WhatsApp integration, enabling message querying, searching, sending, and activity summaries through a stdio-based Model Context Protocol interface
WhatsApp MCP has well-structured tool definitions with complete schemas and descriptions for all 8 tools. All tools follow verb_noun naming conventions (list_*, get_*, send_*, search_*, download_*, catch_up). Descriptions are detailed and explain context (e.g., 'Always sorted by last activity and includes last message preview' for list_chats). However, several parameter descriptions lack detail about constraints, valid values, and error recovery guidance. Schema depth is good with proper JSON types and field descriptions present. No critical security issues detected. Main gaps: missing enum constraints on 'timeframe' and 'media_type' parameters, no output schema documentation, and no error handling guidance in descriptions.
List recent WhatsApp conversations with message previews, sorted by most recent activity. Search by contact/group name or phone number to find specific conversations. Supports groups-only filtering and pagination.
List messages from a conversation. Filter by contact/group name and optionally by date range. Returns messages with content, sender, timestamp, and media type.
Search message content across all conversations. Supports keywords, exact phrases ("project meeting"), boolean operators (OR/AND), exclusion (-word), and wildcards (vacat*). Returns matching messages with ±2 surrounding messages for context.
Send a text message, media file (image/video/audio/document), or both to a WhatsApp contact or group. Supports replying to messages for threaded conversations. Audio files are sent as voice messages.
Timeframe parameter lacks enum constraint. Values are documented as natural strings ('last_hour', 'today', etc.) but not formalized as an enum in the schema. This invites hallucinated timeframe values from LLMs.
No output schema documentation. Tool descriptions describe what is returned informally (e.g., 'includes last message preview') but no formal JSON schema is documented for responses. This prevents agents from planning downstream operations.
Error handling descriptions are absent. No guidance on what errors are possible (e.g., 'User not found', 'Message not found', 'Recipient invalid') or how to recover. LLMs cannot self-correct without actionable error messages.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 0 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Recipient parameter in send_text and send_media accepts multiple formats (phone, JID, group JID) but lacks validation hints. Description should specify expected format and constraints (e.g., 'Phone number without +', 'Must be valid JID format').
Media_path parameter in send_media has no validation constraints. Should document accepted file types, size limits, and format requirements (e.g., 'Local file path, max 100MB, accepted: JPEG, PNG, MP4, M4A, PDF').
send_text and send_media are write operations but descriptions do not explicitly state 'This action sends a message and cannot be undone' or suggest confirmation patterns. State side effects clearly.
Pagination parameters (limit, page) in list_chats, list_messages, and search_messages lack documented bounds. Should specify min/max (e.g., 'limit: 1-200, default 20' and 'page: 0-indexed').
get_chat parameter 'chat_jid' has minimal description ('The JID of the chat to retrieve'). Should clarify JID format and provide examples of valid formats (e.g., '+1234567890@s.whatsapp.net' for direct messages, 'group-id@g.us' for groups).