Loading ToolBench
WhatsApp ChatGPT-powered multimodal AI chatbot in PHP using Wassenger API
This is a WhatsApp bot integration that exposes 5 tools via function calling to OpenAI/ChatGPT. The codebase reveals PHP code calling external APIs (Wassenger) and OpenAI. However, critical inspection of the tool definitions in src/Bot/FunctionHandler.php shows severe deficiencies: (1) Tool names lack action verbs and are inconsistently formatted (getPlanPrices, loadUserInformation, bookSalesMeeting use mixed camelCase instead of snake_case verb_noun convention). (2) Descriptions are extremely sparse or generic, most are 1-2 sentences with no guidance on WHEN to use each tool, WHAT it returns, or WHAT prerequisites exist. (3) Input schemas are nearly absent: getPlanPrices, loadUserInformation, and currentDateAndTime have empty objects {}; only verifyMeetingAvailability and bookSalesMeeting declare a 'date' parameter but lack descriptions for that parameter. (4) No output schemas are documented anywhere, the agent cannot plan downstream calls. (5) No error handling guidance, tools silently fail or return opaque API errors. (6) No parameter descriptions, the 'date' field in two tools lacks type guidance beyond the bare 'format: date-time'. This server is not suitable for production agent deployment.
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
No input schemas for 3 of 5 tools (getPlanPrices, loadUserInformation, currentDateAndTime declare empty {} objects).
Tool names do not follow verb_noun convention (arcade.dev/patterns/tool baseline: 90% of A+ tools start with action verb). Names like 'getPlanPrices', 'loadUserInformation' use camelCase instead of snake_case, and lack consistent verb prefixes. LLMs struggle to parse intent from irregular naming.
Descriptions are too brief (10-40 chars for most). Rubric baseline: 194 chars average, p10=34. getPlanPrices ('Get available plans and prices...') lacks context on WHEN to call it vs other tools, WHAT structure it returns, and any filtering options. No guidance on prerequisites.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 24 | <=2025-11-25 | v2 |
Parameter 'date' in verifyMeetingAvailability and bookSalesMeeting lacks description. Rubric critical check: 'Every parameter needs a description.' Without it, the LLM cannot infer expected format, timezone, whether past dates are valid, or range constraints.
No output schemas documented for any tool. Rubric critical check: 'Document the output schema. LLMs need to know what fields to expect.' Without this, agents cannot plan chaining calls or extract required data (e.g., what fields does loadUserInformation return? user_id? user_name? Both?).
No error handling guidance. Tools offer no recovery hints (pattern:recovery-guide). If bookSalesMeeting fails due to 'time slot booked', the agent sees only an API error with no guidance on what to do next (retry? try different time? ask user?).
bookSalesMeeting is a WRITE tool with destructive intent (books a meeting, a real-world commitment) but has no confirmation/dry-run option. Rubric critical: 'Irreversible operations should support a dry-run or confirmation step.' Agents may accidentally double-book or book incorrect times without a safety net.
Parameter descriptions are missing or vague. The 'date' field in two tools declares format='date-time' but provides no description of: expected timezone, whether past dates are valid, or how to interpret ambiguous times (e.g., does '2024-12-25 14:00' mean UTC or user's local time?).