Loading ToolBench
Read-only WhatsApp MCP server — reads chats/media, builds client-context docs. Cannot send.
WhatsApp MCP has well-structured tool names (verb_noun pattern) and comprehensive parameter schemas with types and descriptions. However, tool descriptions are inconsistent in depth, some are detailed (build_client_context, send_message) while others are terse (search_contacts, find_chat_by_number). Output schemas are not documented, and error handling guidance is absent. No tool annotations (readOnlyHint/destructiveHint) despite clear risk stratification. Parameter descriptions are generally good (72 chars avg), but lack constraint details (e.g., phone number format, JID format). The server correctly identifies WRITE vs READ_ONLY risks but does not expose this to the LLM via annotations.
★ Pull the WHOLE conversation with a client number into a ready-to-work context. Writes context/<number>/CONTEXT.md (their requirements, full transcript, a media table, and every link they shared) and downloads all photos/videos/docs into a media/ folder. Give it the client's number and start working from CONTEXT.md.
Decrypt+download one media file (by message_id + chat_jid). Returns the local file path.
Resolve a phone number (any format, e.g. +91 98765 43210) to its 1:1 chat + metadata.
List WhatsApp chats. Optional `query` filters by name/JID. `sort_by`: 'last_active' or 'name'.
List every media item (image/video/audio/document) shared in a chat, with message IDs.
Read messages (newest first). Filter by chat_jid, sender number, text `query`, or ISO date range.
No output schemas documented. LLMs cannot infer what fields list_chats, list_messages, or download_media return, forcing them to guess at response structure and risking failed downstream tool chains.
No tool annotations (readOnlyHint/destructiveHint). Server internally marks send_message and send_file as WRITE and others as READ_ONLY, but does not expose this via MCP tool annotations. LLMs cannot distinguish safe from destructive tools without reading descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Search your contacts (1:1 chats) by name or phone number.
Send ONE local file (image/video/document, e.g. a code file) to ONE recipient. `recipient` is a phone number or chat JID. One recipient only; rate-limited. Confirm recipient + file with the user first.
Send ONE text message (e.g. a reply or a code snippet) to ONE recipient. `recipient` is a phone number (+91…) or a chat JID. Lists are rejected and the bridge rate-limits sends. Confirm recipient + content with the user first.
Parameter format constraints missing. 'phone_number' and 'chat_jid' parameters lack format specifications (e.g., '+91 98765 43210' or JID structure). LLMs cannot validate input format and may pass malformed values.
No error recovery guidance. Tools lack descriptions of failure modes and recovery steps. E.g., download_media does not explain what happens if media is unavailable or decryption fails.
Confirmation/dry-run missing for destructive operations. send_message and send_file are irreversible but lack a confirmation step or dry-run mode. Agents cannot preview before executing.