Loading ToolBench
An MCP server for Cal.com that provides access to calendar, scheduling, bookings, and user management APIs
This MCP server has serious definition quality issues. Of 17 tools, 9 tools (getBooking, getBookings, createBooking, rescheduleBooking, cancelBooking, getEventTypes, getEventTypeById, updateEventType, deleteEventType) are defined in src/config.ts but NOT visible in the provided source code, only inferred from the tools list. Per the rubric, inferred tools cap at 50 each. The 8 tools visible in src/tools.ts have partial schema documentation but suffer from weak descriptions and missing parameter documentation. Tool names are auto-generated (CalProviderController_verifyClientId) and do not follow verb_noun convention. Parameter descriptions are sparse or missing entirely. No output schemas are documented. Error handling guidance is absent. The server relies entirely on pass-through API definitions without LLM-friendly wrapping.
Cancel a booking
Create a booking
Create a managed user
Delete an event type
Delete a managed user
If you have lost managed user access or refresh token, then you can get new ones by using OAuth credentials. Each access token is valid for 60 minutes and each refresh token for 1 year. Make sure to store them later in your database, for example, by updating the User model to have `calAccessToken` and `calRefreshToken` columns.
Get a booking
Nine of 17 tools (getBooking, getBookings, createBooking, rescheduleBooking, cancelBooking, getEventTypes, getEventTypeById, updateEventType, deleteEventType) defined in src/config.ts are not visible in provided source code. These tools receive 0 scores and cannot be properly evaluated.
Tool names do not follow verb_noun convention. Generated names like 'CalProviderController_verifyClientId' and 'OAuthClientUsersController_getManagedUsers' are unnecessarily long and do not start with clear action verbs. LLMs struggle to parse intent from controller-prefixed names. Should be 'get_provider', 'get_managed_users', 'create_user', etc.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 26 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 33 | - | v1 |
Get all bookings
Get an event type by ID
Get all event types
Get all managed users
Get a managed user
Reschedule a booking
Update an event type
Update a managed user
Verify an access token
Get a provider
Parameter descriptions are sparse or missing entirely. For example, verifyClientId accepts only 'clientId' but the description 'Get a provider' does not explain what 'provider' means, when to call this vs verifyAccessToken, or what the response contains. LLMs cannot select tools without clear descriptions of what each parameter controls.
No output schemas are documented. Tools return HTTP responses but the definition provides no indication of what fields are returned, their types, or structure. LLMs cannot plan downstream tool calls or extract required IDs (e.g., userId for deleteUser) without knowing what createUser returns.
No error handling guidance. Tools are defined with no recovery instructions, error categories, or actionable messages. If a delete_user call fails (e.g., user not found, insufficient permissions), the LLM receives no guidance on how to recover or what to do next.
Destructive operations (deleteUser, cancelBooking, deleteEventType) lack confirmation or dry-run support. Agents can invoke delete_user with no safeguard, no preview of what will be deleted, and no confirmation step. Irreversible operations should support a confirm pattern.
Parameter documentation is minimal. createUser accepts 'timeZone' but does not state the expected format (IANA identifier like 'America/New_York' vs UTC offset vs abbreviation). 'locale' accepts an enum but does not explain which languages these codes represent or how they affect the user experience.
API credentials (OAuth clientId, access tokens) are passed as path parameters or returned in responses. According to the security pattern, credentials should use server-side injection and never appear in tool parameters or responses. Current design risks leaking tokens into agent logs and prompt history.
No mention of pagination, rate limits, or result caps. getManagedUsers accepts limit and offset, but there is no documented maximum result size, no guidance on pagination behavior, and no warning about context window exhaustion if the LLM requests 10,000 users.