Loading ToolBench
An MCP server for managing CalDAV calendars, supporting Google Calendar and Apple iCloud via OAuth2 and Basic authentication
This CalDAV MCP server exhibits moderate definition quality with significant inconsistencies. Tool naming follows verb-noun convention reasonably well (auth_google, fetch_calendars, create_calendar_object), but descriptions vary widely in quality and completeness. Input parameters are defined with types and descriptions in the visible schema, but output schemas are not explicitly documented. The server handles sensitive credentials (passwords, OAuth tokens) appropriately by storing them server-side rather than exposing them as parameters, which is a security best practice. However, several tools lack contextual information about prerequisites, error conditions, and return value structures that would optimize LLM selection and planning.
Authenticate with Apple iCloud Calendar using Basic authentication
Authenticate with Google Calendar using OAuth2
Create a new calendar object (event) in a calendar
Delete a calendar object (event)
Fetch calendar objects (events) from a calendar, optionally filtered by date range
Fetch all calendars for the authenticated account
Update an existing calendar object (event)
Output schemas not documented. While input schemas are visible (code, account, password, calendarUrl, data, start, end), return value structures are entirely undocumented. LLMs cannot infer what fields to expect from create_calendar_object, fetch_calendars, etc., forcing them to guess whether returns include event IDs, HTTP status codes, error details, or structured metadata needed for downstream tool chains.
Tool descriptions are generic and lack situational context. 'Authenticate with Google Calendar using OAuth2' does not explain when to call this vs auth_apple, what scopes are required, or what to do if the authorization code fails. 'Fetch all calendars' omits whether this returns only primary calendar or all accessible calendars, whether it includes sharing metadata, or pagination limits.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No documentation of required prerequisites or dependencies. fetch_calendars, create_calendar_object, and other tools implicitly require prior authentication via auth_google or auth_apple, but this dependency is not stated in descriptions. LLMs may attempt to call fetch_calendars without authenticating first, resulting in errors.
Error handling guidance absent. Tools like delete_calendar_object (marked DESTRUCTIVE) have no documented error cases or recovery paths. What happens if the calendarObjectUrl is invalid? Does the tool return a 404, throw an exception, or silently fail? No actionable error messages guide the LLM on what to do next.
No confirmation mechanism for destructive operations. delete_calendar_object is marked DESTRUCTIVE but offers no dry-run, confirmation, or undo capability. An LLM could irreversibly delete all calendars in a retry loop without any guard rails.
Insufficient parameter guidance for complex inputs. create_calendar_object and update_calendar_object accept 'data' as an iCalendar (ICS) string but provide no guidance on format, required fields, or how to generate valid ICS. An LLM unfamiliar with iCalendar RFC 5545 will struggle to construct valid input.
Date range parameters (start, end) in fetch_calendar_objects lack format specification or bounds. Description states 'ISO 8601 format' but does not clarify whether times are required, whether timezones are supported, or what happens if end < start.
Missing tool composition guidance. fetch_calendar_objects returns events but does not document whether returned event objects include IDs usable by update_calendar_object or delete_calendar_object. Without this clarity, LLMs cannot chain these tools effectively.