Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@iCal MCP Server list events from my work calendar this week"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A modern Model Context Protocol (MCP) server for managing iCalendar files. This server allows AI assistants to interact with calendar data through a standardized protocol.
Load calendars from:
Local files (.ics)
HTTP/HTTPS URLs
Query events with filters for:
Date ranges
Search text (summary, description, location)
Location
Recurring event expansion
Full CRUD operations:
Create new events
Update existing events
Delete events
Multiple calendar support: Load and manage multiple calendars simultaneously
Read-only mode: HTTP calendars are automatically read-only
Related MCP server: Google Calendar MCP Server
You can run the server directly without installation:
npx @jonas/ical-mcpnpm install -g @jonas/ical-mcp
ical-mcpgit clone https://github.com/jnss95/ical-mcp.git
cd ical-mcp
npm install
npm run build
npm startCalendars are configured using environment variables at startup:
Variable | Description |
| URL or path to a calendar (id defaults to "default") |
| URL or path to a calendar with custom id |
Examples:
Single calendar (id defaults to "default"):
CALENDAR_LINK=https://example.com/calendar.icsMultiple calendars with custom IDs:
CALENDAR_LINK_work=https://example.com/work.ics
CALENDAR_LINK_personal=/path/to/personal.ics
CALENDAR_LINK_holidays=https://example.com/holidays.icsAdd to your VS Code settings (.vscode/mcp.json):
{
"servers": {
"ical": {
"type": "stdio",
"command": "npx",
"args": ["@jnss95/ical-mcp"],
"env": {
"CALENDAR_LINK": "https://example.com/your-calendar.ics"
}
}
}
}With multiple calendars:
{
"servers": {
"ical": {
"type": "stdio",
"command": "npx",
"args": ["@jnss95/ical-mcp"],
"env": {
"CALENDAR_LINK_work": "https://example.com/work.ics",
"CALENDAR_LINK_personal": "/path/to/personal.ics"
}
}
}
}Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"ical": {
"command": "npx",
"args": ["@jnss95/ical-mcp"],
"env": {
"CALENDAR_LINK": "https://example.com/your-calendar.ics"
}
}
}
}Tool | Description |
| List all loaded calendars |
| Get metadata about a loaded calendar |
Tool | Description |
| List all events in a calendar |
| Search events with filters |
| Get details of a specific event |
| Create a new event |
| Update an existing event |
| Delete an event |
{
"tool": "list_calendars",
"arguments": {}
}{
"tool": "search_events",
"arguments": {
"calendarId": "work",
"startDate": "2024-01-01T00:00:00Z",
"endDate": "2024-01-31T23:59:59Z",
"searchText": "meeting",
"expandRecurring": true
}
}{
"tool": "create_event",
"arguments": {
"calendarId": "work",
"summary": "Team Meeting",
"start": "2024-01-15T10:00:00Z",
"end": "2024-01-15T11:00:00Z",
"description": "Weekly team sync",
"location": "Conference Room A"
}
}{
"tool": "create_event",
"arguments": {
"calendarId": "work",
"summary": "Daily Standup",
"start": "2024-01-15T09:00:00Z",
"end": "2024-01-15T09:15:00Z",
"rrule": "FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR"
}
}{
"tool": "update_event",
"arguments": {
"calendarId": "work",
"eventId": "event-uid@example.com",
"summary": "Updated Meeting Title",
"location": "New Location"
}
}# Run all tests
npm test
# Run tests with coverage
npm run test:coverage
# Run tests in watch mode
npm run test:watch# Build TypeScript
npm run build
# Watch mode
npm run watchical_mcp/
├── src/
│ ├── index.ts # MCP server entry point
│ ├── calendar/
│ │ ├── calendar.ts # Calendar class (CRUD operations)
│ │ ├── loader.ts # Calendar loading utilities
│ │ └── index.ts # Module exports
│ └── types/
│ ├── calendar.ts # Type definitions
│ ├── ical.d.ts # ical.js type declarations
│ └── index.ts # Type exports
├── build/ # Compiled JavaScript
├── package.json
├── tsconfig.json
└── vitest.config.tsMIT
Create a new event in the calendar.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | End date/time (ISO 8601 format). If not provided, defaults to start + 1 hour | |
| url | No | Event URL | |
| rrule | No | Recurrence rule (e.g., "FREQ=WEEKLY;COUNT=10") | |
| start | Yes | Start date/time (ISO 8601 format, e.g., "2024-01-15T10:00:00") | |
| allDay | No | Whether this is an all-day event | |
| status | No | Event status | |
| summary | Yes | Event title/summary | |
| location | No | Event location | |
| attendees | No | List of attendee emails | |
| organizer | No | Organizer email | |
| calendarId | Yes | The calendar identifier | |
| categories | No | Event categories | |
| description | No | Event description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the action. It does not mention permission requirements, side effects, defaults, or what happens on success/failure. This is comparable to a minimal 'Update' description that also scored 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. However, it is under-specified given the tool's complexity, so it loses a point for not earning its place with more substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 13-parameter create tool with no output schema and no annotations. The description provides almost no context about required inputs, defaults, or expected outcomes, leaving the agent to rely solely on the schema. For a mutation tool with this complexity, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, so the description does not need to add parameter details. It adds no additional meaning beyond the schema, but the baseline of 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create a new event in the calendar.' This clearly distinguishes it from sibling tools like update_event, delete_event, and list_events. The resource (event) and scope (calendar) are both named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that this is for creating new events, as opposed to updating or deleting, and gives no prerequisites or context about when creation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an event from the calendar.
| Name | Required | Description | Default |
|---|---|---|---|
| eventId | Yes | The event UID to delete | |
| calendarId | Yes | The calendar identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It does not mention that deletion is irreversible, whether special permissions are required, or what happens if the event does not exist. This lack of context is significant for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It is appropriately brief for a simple operation, though it could be more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool with no annotations and no output schema, the description is too sparse. It does not explain return behavior, error handling, or side effects, leaving the agent without enough context to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (eventId and calendarId) have descriptions in the schema, providing full coverage. The description itself does not add any additional parameter detail, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete an event from the calendar' uses a specific verb and resource, making it immediately clear what the tool does. It also distinguishes it from sibling tools like create_event and update_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as update_event or get_event. The description does not mention any prerequisites, exclusions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata and information about a loaded calendar.
| Name | Required | Description | Default |
|---|---|---|---|
| calendarId | Yes | The calendar identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Get metadata and information' but does not clarify what 'metadata and information' includes, error behavior, or required state (e.g., what 'loaded' means). Minimal behavioral detail beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no waste. It immediately states the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description is adequate but leaves ambiguity about return format and the 'loaded' prerequisite. Since there is no output schema, it could have explained what 'metadata and information' entails, but the core purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter calendarId is already fully described in the schema as 'The calendar identifier' (100% coverage). The description adds no additional semantic meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with resource 'metadata and information about a loaded calendar', clearly distinguishing it from sibling tools like list_calendars or get_event. It precisely conveys what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need metadata for a specific calendar by ID, but it does not explicitly state when to use this vs alternatives (e.g., list_calendars for enumerating calendars). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific event by its UID.
| Name | Required | Description | Default |
|---|---|---|---|
| eventId | Yes | The event UID | |
| calendarId | Yes | The calendar identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must convey behavioral context. It merely states the read action without disclosing error handling, permissions, or response format, providing minimal transparency beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the action and resource without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description could clarify return details or error behavior, but for a simple event retrieval with two well-documented parameters, the description is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema (100% coverage). The description adds little beyond the schema, only referencing UID, which aligns with eventId. No additional semantic value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information about a specific event using its UID, distinguishing it from list/search operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific event UID is known, but does not explicitly contrast with sibling tools like list_events or search_events, leaving the selection guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all currently loaded calendars.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation but does not describe the return format, pagination, or what 'currently loaded' means. This leaves significant room for ambiguity about side effects or state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of six words, with no redundancy. For a zero-parameter tool, this is appropriately concise and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params, no output schema), but the description lacks detail about the return value and the concept of 'loaded' calendars. This could confuse an agent if the response format is crucial for downstream steps, though for a simple listing tool it is minimally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to clarify. The schema is empty and the description adds no parameter-related information, but the baseline for zero-parameter tools is 4 since no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (calendars), with 'currently loaded' adding scope. It distinguishes itself from sibling tools like list_events and get_calendar_info by targeting calendars as a whole.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_calendar_info or list_events. The description does not mention exclusions or prerequisites, leaving the agent to infer appropriate usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all events in a calendar, optionally filtered by date range.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of events to return | |
| offset | No | Number of events to skip (for pagination) | |
| endDate | No | End of date range (ISO 8601 format, e.g., "2024-12-31") | |
| startDate | No | Start of date range (ISO 8601 format, e.g., "2024-01-01") | |
| calendarId | Yes | The calendar identifier | |
| expandRecurring | No | Expand recurring events into individual occurrences (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavior. It mentions listing and date filtering but does not discuss pagination, expandRecurring behavior, default limits, or any side effects. The read-only nature is implied by 'List' but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the key action and resource. Every word adds value, with no filler or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters and no output schema, but the schema provides good field details. The description is adequate for a basic list operation, yet it omits guidance on pagination, recurring event expansion, and response format, which would be useful given the parameter richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover 100% of parameters, so the baseline is 3. The description adds no extra parameter semantics beyond the date range filter, which is already documented in startDate and endDate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists events in a calendar with optional date range filtering, using a specific verb and resource. It does not explicitly mention alternatives like search_events, but the 'all events' scope helps differentiate it from get_event and list_calendars.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for listing events, with optional date range filtering, but provides no explicit guidance on when to use this versus search_events or other sibling tools. It gives context but no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for events matching specified criteria.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results | |
| endDate | No | End of date range (ISO 8601) | |
| location | No | Filter by location | |
| organizer | No | Filter by organizer | |
| startDate | No | Start of date range (ISO 8601) | |
| calendarId | Yes | The calendar identifier | |
| categories | No | Filter by categories | |
| searchText | No | Text to search for in summary, description, and location |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only states that the tool searches; it does not mention that it is a read-only operation, how results are returned, any pagination, or search semantics like case sensitivity. This is a significant gap for a tool with a non-obvious behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no fluff or redundancy. It is front-loaded with the verb and object, making the purpose immediately understandable. There is zero wasted text, meeting the high standard for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and minimal description, the overall context is incomplete. The description does not explain how the search criteria interact, what fields are searched, or what the response looks like. Sibling tools like list_events are not clarified in relation, leaving the agent with significant ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 8 parameters, so the baseline is 3. The tool description itself adds no additional meaning to the parameters, but the schema already documents each parameter's purpose. Therefore, no extra credit is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search for events matching specified criteria' clearly states the tool's action (search) and resource (events), and implies criteria-based filtering. However, it does not differentiate itself from the sibling tool 'list_events', which could also be used to retrieve events, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like list_events or get_event. It does not mention any exclusions, prerequisites, or scenarios where search_events is preferred, leaving the decision to the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing event.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | New end date/time (ISO 8601 format) | |
| url | No | New event URL | |
| rrule | No | New recurrence rule | |
| start | No | New start date/time (ISO 8601 format) | |
| allDay | No | Whether this is an all-day event | |
| status | No | New event status | |
| eventId | Yes | The event UID to update | |
| summary | No | New event title/summary | |
| location | No | New event location | |
| attendees | No | New list of attendee emails | |
| organizer | No | New organizer email | |
| calendarId | Yes | The calendar identifier | |
| categories | No | New event categories | |
| description | No | New event description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It simply says 'Update an existing event' without explaining whether it performs a partial or full update, what happens to omitted fields, required permissions, or idempotency. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short sentence) and front-loaded, but it is under-specified. It conveys the core action but omits valuable context, making it more a minimal placeholder than a well-crafted concise description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, no output schema, no annotations), the description is incomplete. It does not explain update semantics, how optional fields interact, or what happens if no optional fields are provided. The schema covers parameter names but not behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all 14 parameters, so the baseline is 3. The description adds no additional meaning beyond what the schema provides, but it does not need to compensate given the thorough schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('an existing event'), distinguishing it from sibling tools like create_event, delete_event, and get_event. However, it lacks detail about which fields can be updated or any scope, so it is not as strong as descriptions that enumerate specific aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, such as needing the event to exist, or when to prefer create_event for new events. The description leaves usage entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.3create_eventdelete_eventget_calendar_infoget_eventlist_calendarslist_eventssearch_eventsupdate_eventScored across 8 tools
The tools are mostly distinct: list_calendars vs get_calendar_info for calendar list/detail, and list_events vs search_events for broad vs specific retrieval. The only slight overlap is between list_events and search_events, but their descriptions clarify the difference (range vs criteria).
All tools follow a consistent verb_noun pattern using verbs like list, get, search, create, update, delete. The pattern is uniform across calendar and event resources, making the tool API predictable and easy to navigate.
Eight tools is well-scoped for a calendar server covering two resources (calendars and events). It provides a focused set without unnecessary bulk, and each tool serves a clear purpose.
Events have full CRUD coverage (create, read, list, search, update, delete), and calendars have read operations appropriate for loaded calendars. The surface covers the expected workflows without obvious gaps for the stated purpose.
Calendar API for AI agents: events, availability, Google/Microsoft setup, scheduling, and iCal.
GDPR-compliant calendar access for AI assistants: read, create, edit, RSVP. Google, MS 365, Apple.
Manage Google, Outlook & Apple calendars and create private sync rules from chat.
Connects ChatGPT to your Apple Calendar via a local Mac agent + Vercel relay
