Loading ToolBench
WhatsApp/Signal Group Chat Intelligence — MCP server + analysis pipeline
The server defines 7 tools with mostly complete schemas and descriptions. Tool names follow verb_noun convention (list_, get_, send_, reply_to_). All tools have descriptions between 80-200 characters, meeting the baseline. Input schemas are present for all tools with proper JSON Schema format. However, there are significant gaps in output schema documentation, parameter completeness, and error handling guidance. The server lacks tool annotations (readOnlyHint/destructiveHint), output schema documentation, and recovery guidance in error cases. The fuzzy group matching feature is well-implemented but the tool interface could be clearer about ambiguity handling and recovery paths.
Export a WhatsApp group chat as .txt in the same format as WhatsApp built-in export.
Get messages from a WhatsApp group. Supports fuzzy group name matching, message count limit, and date range filtering.
Get detailed metadata about a WhatsApp group including description, participants, and creation date.
List all WhatsApp groups the authenticated user belongs to, sorted by most recent activity.
Reply to a specific message in a WhatsApp group. The reply will be shown as a quoted reply.
Search messages containing a keyword or phrase, optionally scoped to a specific group.
Output schemas are completely undocumented. No tool specifies what fields, types, or structure the response will contain. LLMs cannot plan downstream operations or extract required fields without explicit schema documentation.
Tool annotations are missing. Write operations (whatsapp_send_message, whatsapp_reply_to_message) should be marked with destructiveHint=true. Read-only operations should be marked with readOnlyHint=true. This prevents agents from accidentally treating destructive operations as safe to retry.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Send a message to a WhatsApp group, addressed by name or exact JID. If the name matches more than one group, the send is refused and the matching JIDs are returned instead of guessing.
Error handling lacks recovery guidance. The resolveGroupOrError() function returns ambiguity errors but does not integrate with tool response format or provide actionable next steps. Error responses should explicitly guide the LLM on what to do (e.g., 'Try calling whatsapp_list_groups() to see available groups').
groupName parameter design creates unnecessary friction. Accepting fuzzy names is good, but the parameter description could clarify the fallback and suggest exact JID format more prominently. The description mentions fuzzy matching but doesn't explain what happens on ambiguity or how to resolve with a JID upfront.
Date parameters (afterDate, beforeDate in whatsapp_get_messages) lack validation constraints. Descriptions state 'YYYY-MM-DD' format but do not specify minimum/maximum dates, relative date support, or what happens on invalid input. This invites LLM errors like passing '2024-13-45'.
Pagination support is absent or undocumented. whatsapp_list_groups, whatsapp_get_messages, and whatsapp_search_messages all return lists but do not specify pagination, total count, or cursor tokens. Large result sets could exhaust context window without explicit pagination.
Response field naming consistency is unclear. whatsapp_list_groups likely returns 'groups' or 'group' objects, but downstream tools (whatsapp_send_message) expect 'groupName' input. The contract between tools is not explicit, this forces LLMs to infer field mappings.
whatsapp_export_chat description mentions '.txt format as WhatsApp built-in export' but does not document the actual response structure. Is the file returned as a base64 string? A URL? A file path? LLMs cannot handle the output without knowing its type.