MCP server for iCloud Calendar via CalDAV
Strong tool naming (verb_noun pattern), comprehensive descriptions (150-250 chars each), and complete input schemas with type definitions and parameter descriptions. Tool annotations present (readOnlyHint, destructiveHint, idempotentHint). Key gaps: output schemas not formally documented in code; no pagination support despite potential for large result sets; error messages lack recovery guidance; no confirmation pattern for destructive delete operation despite risk classification.
Create a new event on the specified calendar. Args: - calendar: Display name or full CalDAV URL - summary: Event title (required) - start, end: ISO 8601 datetimes - description, location: optional - allDay: boolean (default false) Returns the created event's uid and CalDAV URL.
Delete an event by UID. Args: - calendar: Display name or full CalDAV URL - uid: Event UID This is destructive. Confirm with the user before invoking.
List all calendars in the authenticated iCloud account. Returns each calendar's display name, URL (used as a stable identifier), color, and timezone if available. Use this when: - The user asks "what calendars do I have" - You need a calendar identifier to pass to other tools - Disambiguating between calendars with similar names
List events from a specific calendar within a time range. Args: - calendar: Display name (e.g. "Work") or full CalDAV URL - start: ISO 8601 datetime for range start - end: ISO 8601 datetime for range end Returns an array of events with uid, summary, start, end, location, description, allDay flag. The 'uid' is the stable identifier — use it for update/delete operations.
Output schemas not formally documented. Tools return structured content via ok() helper with structuredContent field, but no JSON Schema definitions visible for response shapes. LLMs cannot plan downstream operations without knowing return field names and types.
icloud_list_events lacks pagination. No limit, offset, or page_size parameters visible. Large calendars could return hundreds of events, exhausting context window. Baseline: paginated tools accept limit (1-100) and offset/cursor.
Error handling returns generic messages without recovery guidance. err() helper returns 'Error: {message}' with no actionable next steps. Per pattern:recovery-guide, errors should suggest alternatives (e.g., 'Event not found. Try icloud_list_events() to find the correct UID').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2025-06-18+ | v2 |
Update fields on an existing event by UID. Args: - calendar: Display name or full CalDAV URL where the event lives - uid: Event UID (from icloud_list_events) - Any of: summary, description, location, start, end, allDay (only provided fields are updated) Returns confirmation with the updated UID.
icloud_delete_event marked DESTRUCTIVE but no confirmation pattern implemented. Description says 'Confirm with the user before invoking' but tool has no dry-run or confirmation_required annotation. Agents may delete events without user approval.
Parameter descriptions lack format constraints. 'start' and 'end' say 'ISO 8601 datetime' but no regex pattern or example in schema. LLMs may pass invalid formats like '2026-05-01' (missing time) or '2026-05-01T00:00:00' (missing Z). Add pattern or minLength/maxLength to schema.