Loading ToolBench
MCP server for Calendly API integration and scheduling automation
The server has 12 well-defined tools with consistent naming (verb-first pattern), clear descriptions, and proper JSON Schema input definitions. However, several critical gaps reduce quality: (1) Output schemas are not documented, responses are generated as text strings (e.g., 'Event Details:\n${JSON.stringify(data, null, 2)}') rather than structured objects. LLMs cannot infer output field names for downstream tool chaining. (2) Error handling is absent, no recovery guidance, error classification, or actionable messages visible in the code. (3) No parameter descriptions for enum values (e.g., status: 'active'|'canceled' lacks explanation of what each means). (4) Several parameters lack format/constraint guidance (e.g., 'ISO 8601 format' stated in description but no regex pattern in schema). (5) The schedule_event tool combines name/first_name/last_name as alternatives but no clear xor constraint documented. (6) No tool annotations (readOnlyHint, destructiveHint) present. The server demonstrates solid baseline quality but lacks production-grade polish for error recovery and output structure.
Cancel a specific event
Exchange authorization code for access and refresh tokens
Get the current authenticated user information
Get details of a specific event
Get available time slots for a specific event type
Generate OAuth authorization URL for user authentication
Output schemas not documented. Tools return responses formatted as plain text JSON strings (e.g., 'Event Details:\n${JSON.stringify(data, null, 2)}') instead of structured objects. LLMs cannot infer field names or types for downstream chaining. Violates pattern:tool and pattern:response-shaper.
No error handling guidance. Code lacks recovery hints, error classification (retryable vs fatal), or actionable messages. Tools will fail silently without telling LLMs what corrective action to take. Violates pattern:recovery-guide and pattern:error-classification.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 57 | - | v1 |
List invitees for a specific event
List available event types for scheduling meetings
List scheduled events for the authenticated user
List organization memberships for the authenticated user
Refresh access token using refresh token
Schedule a meeting by creating an invitee for a specific event type and time
Enum values lack descriptions. status parameter in list_events and list_event_invitees declares enum ['active', 'canceled'] but does not explain what each state means (e.g., is 'active' scheduled vs confirmed? Does 'canceled' include user cancellation vs system cancellation?). Violates pattern:constrained-input.
schedule_event parameter ambiguity. invitee_name is described as 'alternative to first_name/last_name' but no explicit xor constraint is enforced or documented in schema. LLMs may pass all three, causing unclear precedence. Should add 'oneOf' schema constraint or explicit mutually-exclusive note.
No destructive tool annotations. cancel_event is marked DESTRUCTIVE but the tool definition lacks a destructiveHint annotation. schedule_event is WRITE (creates data) but lacks idempotentHint status. These annotations guide agent caution and retry logic. Violates pattern:tool.
Pagination not fully documented. list_events, list_event_invitees, list_organization_memberships, and list_event_types all accept 'count' parameter but do not document whether results are paginated. No next_cursor, page_token, or offset field is mentioned. Violates pattern:paginated-result.
Format constraints not formalized. get_event_type_availability and schedule_event describe parameters as 'ISO 8601 format' but JSON Schema lacks format constraint (e.g., format: 'date-time'). refresh_access_token accepts refresh_token parameter but description does not specify format or length constraints, inviting hallucinated tokens.
get_current_user lacks output schema documentation. No description of what fields are returned (e.g., user_uri, name, email, organization). Required for agents to know how to reference the current user in downstream calls.