icloud-calendar-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CALDAV_URL | No | Override for a non-iCloud CalDAV server | https://caldav.icloud.com |
| ICLOUD_USERNAME | Yes | Full iCloud email address | |
| ICLOUD_APP_PASSWORD | Yes | App-specific password | |
| CALDAV_DEFAULT_TIMEZONE | No | IANA name used for input times with no offset, and for rendering times back | UTC |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_calendarsA | List the iCloud calendars available to the account, with their names and CalDAV URLs. Use this to discover the exact |
| create_eventA | Publish a new event to an iCloud calendar. Returns the created event's ID (its iCalendar UID). Times are ISO 8601; a value with no UTC offset is read in the configured default timezone. Give date-only values for both |
| get_eventA | Fetch one event by its |
| update_eventA | Change an existing event. Only the fields you pass are changed; pass an empty string to clear |
| delete_eventA | Delete an event. Without |
| list_eventsA | Fetch events from an iCloud calendar within a time range. Defaults to the next 30 days when no range is given. Recurring events are expanded, so each occurrence in the range is returned separately. Ranges longer than 400 days are rejected. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool maps to a distinct resource and action: list_calendars handles calendar discovery, while create/get/update/delete_event and list_events cleanly separate single-event, bulk-listing, and write operations. Recurring-event behavior is described carefully so get_event and list_events are not confused.
All tool names follow a consistent snake_case verb_noun convention: list_calendars, create_event, get_event, update_event, delete_event, list_events. The only variation is singular vs. plural nouns, which is appropriate for single-resource vs. collection operations.
Six tools is well-scoped for a calendar integration: four event lifecycle operations plus calendar discovery and range-based event listing. Each tool has a clear purpose and none feel redundant.
Event CRUD is fully covered, including recurring-event exceptions and range queries, and calendar discovery exists to support event operations. Minor gaps remain, such as no calendar creation/update/delete and no attendee/invitation management, but the core scheduling workflow is complete.