Loading ToolBench
MCP Server for Appointment Booking System - Compatible with Claude Desktop
Server has 14 tools with basic schemas and descriptions, but exhibits significant quality gaps across definition patterns. All tools have descriptions and input schemas are visible, which is positive. However, descriptions are terse (averaging ~60 chars), parameter descriptions are minimal or absent, output schemas are undocumented, and error handling guidance is missing. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present. The server accepts no natural identifiers, all operations require system IDs (serviceId, bookingId, userId) with no fallback to email, name, or username. Parameter validation is weak; no enums are used for constrained fields like 'status' or 'role'. Security concerns include accepting passwords as plain parameters and no evidence of permission gating for admin-only operations. Tool composition is reasonable (each tool has a single responsibility), but critical tools like create_booking and cancel_booking lack idempotency guarantees or confirmation patterns. This server would not pass code review at a production-grade agent toolkit vendor.
Cancel an existing booking
Create a new appointment booking
Create a service provider/resource (organiser only)
Create a new service (organiser only)
Get system statistics (admin only)
Get list of all users (admin only)
Get available time slots for a specific service on a given date
No output schemas documented. LLMs cannot predict return types, fields, or structure for any tool. This blocks downstream tool composition and forces agents to infer output by trial and error. Every tool must document what fields it returns.
Password accepted as plain parameter in login tool. Credentials must never be tool parameters, they leak into agent traces, logs, and prompt history. Implement server-side secret injection via environment variables or vault.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. The MCP spec (2026-07-28) includes structured tool capability hints that let agents reason about safety and composability. All tools should declare whether they read-only, destructive, or idempotent.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 10 | - | v1 |
Get all your appointment bookings
Get all bookings for organiser's services (organiser only)
Get peak booking hours report (admin only)
Get all resources for a service
Get list of all published services available for booking
Login to the appointment booking system and get authentication token
Update user status or role (admin only)
Constrained fields lack enums. 'status' param in get_organiser_bookings accepts free-form string ('pending, confirmed, cancelled') but no enum is defined. Similarly, 'role' in update_user_status has no enum constraint. This invites hallucinated invalid values from LLMs.
No natural identifiers accepted. All tools require system IDs (serviceId, bookingId, userId). Users say 'cancel my appointment' or 'show me bookings for [email protected]', not 'cancel booking B12345'. Tools should accept email, username, or display name and resolve to ID internally.
Missing error handling guidance. No tool documents what errors can occur, which are retryable, or what the agent should do next. A bare API error or empty catch block leaves agents unable to recover. Every tool must include recovery guidance for expected failures.
Destructive operations lack confirmation pattern. cancel_booking, update_user_status, and delete-equivalent operations (if any) should support a dry-run or explicit confirmation step. Agents make mistakes, a confirm_before_execute pattern prevents catastrophic data loss.
No permission gating visible in tool implementations. Admin-only tools (get_admin_stats, get_admin_users, update_user_status, create_service, create_resource) should enforce permission checks before execution. Code inspection of server.js shows no auth validation logic in the provided excerpt.
Parameter descriptions sparse or missing. Most parameters have minimal descriptions; many lack expected format/range details. E.g., 'date' param says 'Date in YYYY-MM-DD format' (good), but 'dayOfWeek' in create_service has no description of valid range (0-6? 1-7?). Descriptions average ~40 chars, well below the 72-char production baseline.
Pagination not implemented. get_services, get_admin_users, and get_organiser_bookings return lists with no mention of limit enforcement, total count, or next_cursor. Large result sets blow context windows. Every list-returning tool must support offset/limit and return a total or cursor.
No idempotency guarantees. create_booking, create_service, create_resource, and cancel_booking do not document idempotency keys or retry safety. If an agent retries a failed create_booking, will a duplicate be created? Agents retry on ambiguous failures, non-idempotent tools risk side effects.