Loading ToolBench
MCP server for Google Calendar integration deployed on Cloudflare Workers with Auth0 authentication and CIBA-based user approval for sensitive operations
This server demonstrates solid MCP implementation with 10 well-defined tools covering Google Calendar operations. Tool naming follows verb_noun conventions (list_calendars, create_event, get_event, etc.), descriptions are present and reasonably detailed (100-250 chars avg), and input schemas are properly defined with JSON Schema types and descriptions. However, several issues prevent a higher score: (1) Output schemas are not documented in the code, we can see inputs but not what each tool returns, which prevents LLMs from planning follow-up calls; (2) Parameter descriptions lack some specificity, e.g., 'Event ID' for eventId is minimal, missing guidance on how to obtain one; (3) Error handling is invisible in this code snapshot, no evidence of recovery guidance or categorized error messages; (4) The create_event tool's CIBA (Client-Initiated Backchannel Authentication) flow is complex and underdocumented, the description mentions approval workflow but lacks step-by-step guidance for agents; (5) No evidence of idempotency markers or confirmation patterns for destructive operations (delete_event).
Create a new calendar event. Requires user approval via push notification (CIBA). First call initiates approval request and returns auth_req_id. Subsequent calls with auth_req_id check approval status.
Delete a calendar event
Get details of a specific event
Check free/busy status for calendars
Get today's agenda - all events for today
List all calendars the user has access to
Output schemas not documented. Tool definitions show input schemas but no documented return types. LLMs cannot plan multi-step workflows when they don't know what fields a tool produces. This violates the SCHEMAS & OUTPUT pattern.
delete_event lacks confirmation pattern. Destructive operations should support dry-run or require explicit confirmation. No evidence of a 'confirm_delete' step or return value acknowledging the destructive action. This is a critical pattern gap.
create_event CIBA flow is underdocumented for LLM consumption. The description mentions 'Requires user approval via push notification' and 'auth_req_id' but lacks step-by-step guidance: What happens between the first and second call? How long does approval take? What error indicates rejection? LLMs will struggle with this multi-step pattern without explicit workflow documentation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 79 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
List events from a calendar within a time range
Create an event using natural language (e.g., "Meeting with Bob tomorrow at 3pm")
Search for events by query text
Update an existing calendar event
Parameter descriptions are generic and lack actionable constraints. Examples: 'Event ID' (missing: where to get it, format), 'Calendar ID' (missing: that 'primary' is a special value), 'Query' in search_events (missing: supported syntax, field names). Descriptions should follow the pattern 'What it does, how to get valid values, example if pattern-based.'
Timezone parameter in get_todays_agenda lacks enum constraint. The description says '(e.g., America/Los_Angeles)' but does not declare valid values. LLMs will hallucinate invalid timezone strings. Replace with enum of IANA timezone identifiers or add strict validation with error guidance.
No evidence of error handling or recovery guidance. The code does not show what happens when a tool fails (invalid calendar ID, permission denied, CIBA rejection). Error responses should categorize failures (retryable vs. fatal) and guide the agent's next step.
No tool annotations visible. Input schemas should include readOnlyHint, destructiveHint, and idempotentHint fields to signal tool characteristics to the agent. delete_event should have {"destructiveHint": true}, list_calendars should have {"readOnlyHint": true}. This is required by the current MCP spec (2026-07-28) for safe agent planning.