iCloud Calendar MCP Server

Overview Schema Source Related Servers Discussions Admin

create_event

Add a new iCloud Calendar event with title, times, location, notes, reminders, and recurrence rules to schedule meetings or appointments.

Instructions

Create a new calendar event.

Before using this tool, make sure to:

Ask the user which calendar they want to use if not specified (check calendars://list)
Ask if they want to add a location if none provided
Ask if they want to add any notes/description if none provided
Confirm the date and time with the user
Ask if they want to set reminders for the event

Args: title: Event title start_time: Start time in ISO format (YYYY-MM-DDTHH:MM:SS) end_time: End time in ISO format (YYYY-MM-DDTHH:MM:SS) notes: Optional event notes/description. Ask user if they want to add notes. location: Optional event location. Ask user if they want to specify a location. calendar_name: Optional calendar name. Ask user which calendar to use, referencing calendars://list. all_day: Whether this is an all-day event reminder_offsets: List of minutes before the event to trigger reminders e.g. [60, 1440] means two reminders, the first 24 hours before the event and the second one hour before. recurrence_rule: Optional recurrence rule for the event. This should be an instance of RecurrenceRule with the following fields: - frequency: Frequency of the recurrence (e.g., DAILY, WEEKLY, MONTHLY, YEARLY). - interval: Interval between recurrences (e.g., every 2 weeks). - end_date: Optional end date for the recurrence. If specified, the recurrence will stop on this date. - occurrence_count: Optional number of occurrences. If specified, the recurrence will stop after this many occurrences. - days_of_week: Optional list of weekdays for the event. Use integers to represent days: - Sunday: 1 - Monday: 2 - Tuesday: 3 - Wednesday: 4 - Thursday: 5 - Friday: 6 - Saturday: 7

Note: Both end_date and occurrence_count should not be set simultaneously; choose one or the other, or leave both unset.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "create_event_request": "<create_event_request>"
    },
    "name": "create_event"
  }
}

Input Schema

Name	Required	Description	Default
`create_event_request`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.1Nov 10, 2026

TDQS

B3.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare openWorldHint=true and destructiveHint=false, so the safety profile is covered externally. The description adds genuinely useful behavioral context the annotations lack: the calendars://list lookup requirement, the reminder-offset semantics, and the mutual-exclusion constraint between end_date and occurrence_count. It says nothing about duplicate/conflict handling or side effects on the target calendar.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the numbered checklist is then restated almost verbatim inside the Args block ("Ask user if they want to add notes", "Ask user which calendar to use"), so a large share of the text is redundant. The recurrence sub-field list is dense but earns its place given the 0% schema coverage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the description covers prerequisites and the recurrence constraint. Gaps remain material for a mutation tool: the undocumented url field, the incorrect frequency encoding, and no statement of what happens on scheduling conflicts or how failures surface.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full documentation burden, and it partly does so field by field. However it names the reminder parameter "reminder_offsets" while the schema field is "alarms_minutes_offsets", and it describes frequency as DAILY/WEEKLY/MONTHLY/YEARLY when the schema requires an integer enum (0-3) – a mismatch that would cause a malformed call. The schema's "url" parameter is not mentioned at all, and the nesting under create_event_request is never disclosed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Create a new calendar event" is a specific verb+resource statement that an agent can immediately map to intent, and it implicitly contrasts with the delete_event/update_event siblings. It stops short of explicitly distinguishing when creation is appropriate versus updating an existing event.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The five-step "before using this tool" checklist is really an interaction protocol (confirm time, ask about location/notes/reminders, pick a calendar via calendars://list), not tool-selection guidance. It never states when to prefer create_event over update_event, nor what to do when an event already exists at that time.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server