Loading ToolBench
A WhatsApp chatbot powered by ChatGPT that integrates with Wassenger API for WhatsApp communication management, featuring AI-driven responses, function calling, and team member assignment capabilities
This server has critical definition quality gaps across all dimensions. While tool names follow verb_noun patterns and schemas are formally declared, most tools lack parameter descriptions, output schemas are undocumented, and error handling is generic. The server implements 5 tools but only 2 provide any parameter documentation. Descriptions are present but most lack the specificity needed for LLM tool selection. This is a STDIO-only server masquerading as HTTP via ASP.NET Core integration with WhatsApp, the actual MCP transport is not visible in the source code provided, which raises protocol concerns.
Book a sales or demo meeting with the customer on a specific date and time
What is the current date and time
Get available plans and prices information available in Wassenger
Find user name and email from the CRM
Verify if a given date and time is available for a meeting before booking it
Output schemas completely undocumented. All 5 tools lack any return type specification. LLMs cannot infer what fields to expect in responses, breaking downstream tool chaining and forcing exploratory calls.
No parameter descriptions for empty-parameter tools. getPlanPrices, loadUserInformation, and currentDateAndTime accept no parameters, yet this design choice is never explained. Why does loadUserInformation not accept a user_id or email? This forces users to guess intent.
Generic error messages with no recovery guidance. ExecuteFunction catches all exceptions and returns 'An error occurred while executing the function' or 'Function not found'. LLMs receive no guidance on whether to retry, ask the user, or abandon the task.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 35 | - | v1 |
currentDateAndTime description is too vague ('What is the current date and time'). This reads as a question, not a tool description. Should be: 'Returns the current server date and time in ISO 8601 format. Use this to verify availability windows or schedule future events.' The LLM cannot determine when this tool is needed vs. relying on its own knowledge.
No idempotency or confirmation pattern for destructive operations. bookSalesMeeting modifies state (WRITE risk) but has no confirmation step, dry-run option, or idempotency guarantee. An agent retry could double-book.
Missing FunctionContext usage and parameter validation. The FunctionContext parameter is threaded through all handlers but never used. VerifyMeetingAvailability and bookSalesMeeting accept a 'date' parameter but never validate format beyond a TryParse attempt. Invalid dates return generic 'Please provide a valid date', no constraint specification.
Tool descriptions do not explain when to use each tool vs. alternatives. 'Get available plans and prices' appears in getPlanPrices, but when should an agent call this vs. directing a user to the website? What is the difference between verifyMeetingAvailability (read-only check) and bookSalesMeeting (write)? No dependency hints provided.