Loading ToolBench
Multi-server MCP implementation for booking, sales (text and voice), vendor management, and website interactions with calendar integration
Severe structural defects across all dimensions. The server registers 13 tools with significant duplication (check_availability, create_booking, contextualize_conversation, and get_information appear 2-3 times each), creating ambiguity for LLM tool selection. Most tool descriptions are present but extremely minimal (10-50 characters), providing insufficient context for when/why an LLM should invoke each tool. Critical parameter descriptions are generic or missing entirely. No output schemas are documented. The server violates foundational composition patterns by duplicating identical tools across different modules (booking.js, sales.text.js, sales.voice.js, vendor.js) without clear functional distinction. Error handling is absent, no recovery guidance, validation, or actionable error messages evident in the codebase. The getWeather tool has a hardcoded mock response (24°C), suggesting prototype-quality implementation. Tool naming partially follows verb_noun convention (check_availability, create_booking, get_information, contextualize_conversation) but inconsistency appears with prefixed tools (run-check_availability, run-create_booking) that duplicate non-prefixed versions. No input validation, parameter constraints beyond basic types, or security considerations visible.
Send the user a booking calendar to book a call or meeting
Fetch available time slots in a user's calendar between two dates.
Fetch available time slots in a user's calendar between two dates.
Fetch available time slots in a user's calendar between two dates.
Request the user's email address to scrape their domain and personalize the conversation.
Request the user's email address to scrape their domain and personalize the conversation.
Duplicate tool registration: check_availability, create_booking, contextualize_conversation, and get_information each registered 2-3 times across different server modules without clear functional differentiation. LLMs cannot distinguish between duplicates and will select arbitrarily, causing unpredictable behavior.
Tool names with 'run-' prefix (run-check_availability, run-create_booking) violate naming convention and duplicate non-prefixed versions. Prefix suggests a shell command pattern inappropriate for MCP tools. Creates ambiguity in tool selection.
Descriptions severely under-specified (10-50 characters) fail to answer WHAT, WHEN, or WHY. Examples: 'Get the weather for the user' (28 chars), 'Send the user a booking calendar to book a call or meeting' (57 chars), 'Request the user's email address to scrape their domain and personalize the conversation' (86 chars). No guidance on prerequisites, return values, or downstream dependencies.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 35 | - | v1 |
Create a booking at a specific date and time
Create a booking at a specific date and time
Get the weather for the user
Retrieve detailed information from your knowledge base for teleperson-specific queries.
Retrieve detailed information from your knowledge base for teleperson-specific queries.
Fetch available time slots in a user's calendar between two dates.
Create a booking at a specific date and time
book_meeting has no input schema (empty {} parameters). LLMs cannot understand what parameters are required or optional, making the tool unusable for structured planning.
No output schemas documented for any tool. LLMs cannot predict return structure, breaking downstream tool chaining. E.g., check_availability returns slots but schema undefined; create_booking's success response format unknown.
Parameter descriptions are minimal or missing. E.g., check_availability's timeZone parameter provides enum but no explanation of why timezone matters or which zone to use if user hasn't specified. contextualize_conversation's email parameter description is bare.
No error handling documented. Tools can fail (API errors, invalid dates, booking conflicts) but no recovery guidance provided. getWeather hardcodes a mock response (24°C, Sunny), indicating prototype-quality. No indication of how to handle invalid inputs or retry logic.
contextualize_conversation asks for 'business email' to 'scrape their domain' for personalization. No documentation of what data is extracted, how it's stored, or what privacy/consent implications exist. Potentially violates principle:secret-injection if email is stored in logs.
create_booking accepts email and attendee details but no validation logic visible. Potential for malformed emails, invalid dates (create_booking accepts date but check_availability requires YYYY-MM-DD format, inconsistent). No confirmation/dry-run for destructive operations.
check_availability requires explicit timezone enum selection. No guidance for LLM on how to determine user timezone if not explicitly stated. Forces extra lookup call or user interaction instead of accepting default or fuzzy matching.