Loading ToolBench
MCP server for WhatsApp integration using Baileys library, enabling chat management, message search, contact lookup, and message sending through Model Context Protocol
The server provides 9 tools with basic but incomplete schema coverage. Naming follows conventions (verb_noun), but descriptions are inconsistent in detail and depth. Most tools have descriptions in the 60-120 character range, which is below the 194-char baseline for A+ tools. Input schemas are present but lack detail, few parameters have minLength/maxLength constraints, enum definitions, or depth documentation. Output schemas are not documented in the source code. Error handling is mentioned in source but not visible in tool definitions. The server follows a READ_ONLY/WRITE risk classification but provides no guidance for recovery or retry logic.
Get detailed information about a specific chat by its JID
Get detailed information about a WhatsApp group including members and metadata
Get a specific message with surrounding context (messages before and after)
List all chats with optional filtering, pagination, and sorting
List all WhatsApp groups with optional filtering and pagination
List messages from a specific chat with pagination
Search for contacts by name or phone number part of JID
Output schemas not documented. No visibility into what fields (beyond JID) list_chats, list_messages, search_messages, or get_chat_info return. LLMs cannot plan downstream tool calls (e.g., passing a message_id to get_message_context) without knowing output field names.
send_message tool description lacks directive about destructive behavior. It says 'Send a text message' but does not explicitly state this is a WRITE operation with side effects, or provide undo/confirmation options. Agents cannot distinguish safe vs. risky calls.
No error recovery guidance in tool descriptions. If send_message fails (e.g. invalid JID, user not found), the description does not tell the LLM what to do next, e.g., 'Use search_contacts to verify the recipient exists' or 'JID must be in format 12345@s.whatsapp.net or groupid@g.us'.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 23 | - | v1 |
Search for messages by text content across all chats or a specific chat
Send a text message to an individual contact or group chat
Parameter constraints missing or underdocumented. 'limit' appears on list_chats, list_messages, search_messages, list_groups with a default of 10-20, but no minimum/maximum bounds are stated. Descriptions do not clarify valid ranges (e.g., 'limit 1 - 100').
JID format not documented in parameter descriptions. Users do not know what a JID is or how to construct one. 'chat_jid' parameter description says 'JID of the chat (e.g. 123@s.whatsapp.net or group@g.us)' but relies on examples rather than explaining the format rule. Replace with formal guidance: 'JID format: individual contacts use 12345@s.whatsapp.net, groups use groupid@g.us'.
Pagination design incomplete. list_chats, list_messages, search_messages accept 'page' and 'limit' but do not document whether results include a total_count, next_cursor, or has_more flag. Without this, agents cannot know when to stop paginating.
Tool composition assumes prior discovery. send_message requires a 'recipient' JID, but there is no explicit guidance linking to search_contacts or list_chats. If an agent only has a name ('Jack'), it must infer to call search_contacts first. Descriptions should say 'Use search_contacts to find a JID if you only have a name.'
get_message_context 'before' and 'after' parameters lack bounds. Descriptions do not state if 0 is valid, or if there is a maximum (e.g., max 50 for performance). Unbounded defaults to 5, but LLMs may try to override with large values.