Loading ToolBench
AI-powered restaurant management and reservation system with voice, WhatsApp, and chat pipelines. Provides tools for reservation management, availability checking, table seating, and host dashboard operations.
This MCP server exhibits severe definition quality issues. While it defines 24 tools (with significant duplication), the schemas are inconsistent, descriptions are minimal and generic, and critical details about error handling, output structure, and parameter constraints are almost entirely absent. Most tools lack descriptions above the baseline 194-char average. Many parameters lack detailed descriptions. Multiple tools are near-duplicates (e.g., check_availability appears twice with identical signatures; create_reservation, lookup_reservation, modify_reservation, cancel_reservation appear in multiple files with slight variation). The server appears to be early-stage, with incomplete tool composition and no evidence of output schema documentation. Parameter validation is not evident. Error recovery guidance is absent.
Cancel an existing reservation. Use lookup_reservation first to verify the reservation exists.
Cancel an existing reservation.
Check if a specific date, time, and party size is available for reservation
Check table availability for a given date, time, and party size.
Check a customer's current position in the queue/waitlist. Use when someone asks about their position, wait time, or says 'posição', 'posicao', 'quanto falta'.
Check if the restaurant has availability for a given date, time, and party size.
Duplicate and near-duplicate tool definitions across files. check_availability, get_current_datetime, create_reservation, lookup_reservation, modify_reservation, and cancel_reservation appear in both api/_services/whatsapp/reservation-tools.js and test-all-mcp-tools.js with subtle schema differences. This creates ambiguity: which is the canonical version? Agents will be confused when they see overlapping tool names with different signatures.
Most tool descriptions are minimal (40-70 chars, well below the 194-char average). Examples: 'Check table availability for a given date, time, and party size.' (66 chars), 'Create a new reservation with customer details.' (48 chars), 'Cancel an existing reservation.' (31 chars). Descriptions lack context on WHEN to use the tool, dependencies on other tools (e.g., 'Call lookup_reservation first before cancel_reservation'), or what success looks like. This violates the pattern:tool-description guideline that descriptions must explain what, when, and next steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Mark a service as complete (customer has finished dining).
Create a new reservation with customer details.
Create a new reservation after confirming all details with the customer
Get active promotions and discount coupons available at the restaurant. Use when the customer asks about promotions, discounts, coupons, or deals.
Get the current date and time. Use this when the customer says 'today', 'tomorrow', or needs to know current time.
Get current date/time information for a given timezone.
Get host dashboard data including current status, tables, and reservations.
Get current wait time for a given party size.
Identify which restaurant the customer wants to book at. Use this first to determine the restaurant.
Add a customer to the restaurant's walk-in queue/waitlist. Use this when someone wants to join the fila/queue/lista de espera. This is NOT for reservations — it's for customers who want to wait for a table right now.
List all available restaurants in the platform. Use when the customer has not specified which restaurant.
List upcoming ticketed events and experiences at the restaurant (wine tastings, chef dinners, brunch events). Use when the customer asks about events, experiences, tastings, special dinners, or says 'eventos', 'degustação', 'brunch'.
Look up an existing reservation by confirmation number or customer phone number.
Look up an existing reservation by confirmation number or customer details.
Mark one or more tables as clean.
Modify an existing reservation. Can change date, time, or party size. Use lookup_reservation first.
Modify an existing reservation (change date, time, or party size).
Seat a party at specific tables.
No documented output schemas. The source code does not reveal what fields these tools return, what structure is used for list results, whether pagination is supported, or what error responses look like. Tools like list_restaurants, list_upcoming_events, and get_host_dashboard_data provide no information on response format, limits, or pagination. This prevents agents from knowing what fields to extract or how to handle large result sets.
Parameter descriptions are sparse or generic. Examples: lookup_reservation accepts 'reservation_id' (description: 'The reservation confirmation number (e.g., RES-20260119-XXXX)') and 'customer_phone' (description: 'Customer phone number to look up reservations') with no guidance on mutually-exclusive inputs (either one suffices but which is preferred?). join_waitlist lacks a 'restaurant_id' parameter but description does not say where restaurant context comes from. Descriptions do not specify formats (phone number format: E.164 or local?), constraints (customer_name: max length?), or validation rules.
No error handling or recovery guidance. No indication of which operations are retryable, what to do if a reservation is not found, or how to handle validation failures (e.g., party_size exceeds max capacity). Tools like cancel_reservation do not document what happens if the reservation is already cancelled. Agents have no guidance on whether to retry, ask the user, or fall back to a different operation.
No evidence of tool annotations (readOnlyHint, destructiveHint, idempotentHint). While the provided data marks some tools as READ_ONLY, WRITE, or DESTRUCTIVE, the source code does not show how these are communicated to MCP clients. Without explicit tool annotations in the schema, clients cannot determine operation impact or safety.
Missing critical parameters in some tools. join_waitlist does not include 'restaurant_id' or 'restaurant_name', how does the server know which restaurant to add the customer to? get_active_promotions, check_queue_position, and get_wait_time lack restaurant context. This suggests either (a) these tools rely on implicit global or session state, or (b) the tool signatures are incomplete. Either way, agents cannot compose these tools reliably.
Inconsistent parameter naming and types across duplicate tools. create_reservation in api/_services/whatsapp/reservation-tools.js has required params [date, time, party_size, customer_name, customer_phone], while the version in test-all-mcp-tools.js reorders them [customer_name, customer_phone, party_size, date, time]. Both accept optional customer_email, but one requires it, the other does not. modify_reservation in reservation-tools.js accepts new_date, new_time, new_party_size (separate params), while the test version accepts date, time, party_size, special_requests. This inconsistency will confuse agents and cause tool invocation failures.
No evidence of LLM-optimized descriptions. The 194-char baseline for A-grade tool descriptions is not met by most tools. Descriptions like 'Check table availability for a given date, time, and party size.' (66 chars) lack actionable context. They do not say: (1) What problem does this solve? (2) When should an agent call this vs another tool? (3) What fields does it return? (4) Are there prerequisites? (5) How does it fail and what should the agent do?
No support for dry-run or confirmation for destructive operations. cancel_reservation and complete_service are destructive but lack a confirmation or preview step. Agents cannot ask users 'Are you sure?' before destroying data. This violates the pattern:confirmation-request guideline.