Kalender Sync

Create event

create_event

Creates an event in one of the calendars this access may write to.

Availability in the requested slot is checked LIVE (not from cache). An overlapping event does NOT prevent creation — the event is created regardless and the overlap comes back as a warning. Pass that warning on to the user instead of silently double-booking; whether the overlap is intended is the user's call.

The check counts only events that BLOCK the time (blocks_time: true in get_availability). Entries that do not block it — holidays, birthdays, and every all-day event from Apple/iCloud — are deliberately not reported as conflicts, because otherwise every booking on a day carrying a holiday would look like a clash. So no warning does NOT mean the day is empty: an all-day "Baustelle Darmstadt" is a working day that will not show up here. When the user asks to book on a specific day, check the day with get_availability first and mention what is already on it.

All-day events: pass bare dates (start: "2026-09-01", end: "2026-09-03") or set all_day: true. For all-day the end date is INCLUSIVE — that example creates a three-day event covering 1–3 September. Both ends must use the same form.

calendar_id is only needed when several calendars are writable; with exactly one, that one is used. list_calendars shows the writable calendars. title is required.

Input Schema

TableJSON Schema

Name	Required	Description
`end`	Yes	End — same form as `start`. For all-day events this date is INCLUSIVE (end 2026-09-03 means the event runs through 3 September).
`start`	Yes	Start — either an ISO 8601 timestamp WITH timezone (2026-07-28T10:00:00+02:00 or …Z), or a bare date (2026-07-28) for an all-day event. A timestamp without a zone is rejected.
`title`	Yes	Event title (required)
`all_day`	No	Force an all-day event; time components in start/end are then discarded. Not needed when start/end are already bare dates.
`location`	No
`time_zone`	No	IANA zone, e.g. America/New_York. For timed events it preserves the NAMED zone so the event follows daylight saving (without it the event is stored as UTC and shows as GMT in Apple Calendar, and a recurring series will not shift with the clocks). For all-day events it decides which local day is covered. Always send it when you know the user's zone; defaults to UTC.
`calendar_id`	No	Target calendar; only needed when several are writable
`description`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`warning`	No
`event_id`	Yes
`calendar_id`	Yes
`calendar_name`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedAug 28, 2026

changedInput schema / properties / time_zone / description

Previous value: -"IANA zone (e.g. Europe/Brussels) deciding which local day an all-day event covers. Defaults to UTC. Ignored for timed events, which carry their own offset."New value: +"IANA zone, e.g. America/New_York. For timed events it preserves the NAMED zone so the event follows daylight saving (without it the event is stored as UTC and shows as GMT in Apple Calendar, and a recurring series will not shift with the clocks). For all-day events it decides which local day is covered. Always send it when you know the user's zone; defaults to UTC."

Changed4 schema fields changedAug 27, 2026

addedInput schema / properties / all_day

Added value: +{
+  "description": "Force an all-day event; time components in start/end are then discarded. Not needed when start/end are already bare dates.",
+  "type": "boolean"
+}

changedInput schema / properties / end / description

Previous value: -"End, ISO 8601 with timezone"New value: +"End — same form as `start`. For all-day events this date is INCLUSIVE (end 2026-09-03 means the event runs through 3 September)."

changedInput schema / properties / start / description

Previous value: -"Start, ISO 8601 WITH timezone — e.g. 2026-07-28T10:00:00+02:00 or …Z. Rejected without a zone."New value: +"Start — either an ISO 8601 timestamp WITH timezone (2026-07-28T10:00:00+02:00 or …Z), or a bare date (2026-07-28) for an all-day event. A timestamp without a zone is rejected."

addedInput schema / properties / time_zone

Added value: +{
+  "description": "IANA zone (e.g. Europe/Brussels) deciding which local day an all-day event covers. Defaults to UTC. Ignored for timed events, which carry their own offset.",
+  "type": "string"
+}

First observedJul 31, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Despite annotations already covering the write/non-destructive profile, the description adds substantial behavior: the availability check is LIVE, an overlap does NOT block creation but returns a `warning` the agent must relay to the user, only `blocks_time: true` events count as conflicts, and all-day Apple/iCloud entries are deliberately excluded. These are non-obvious traits an agent could not infer from the schema or annotations.

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

Conciseness4/5

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

Front-loaded with the core write behavior and the overlap-warning rule, and every paragraph targets a distinct failure mode (double-booking, false conflicts, all-day dates, zone handling). The 'Baustelle Darmstadt' illustration and the DST explanation are slightly verbose, but they justify their length for a semantically tricky tool.

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

Completeness5/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 not be described, yet the description still explains the salient `warning` field. Combined with the all-day, timezone, and calendar-selection rules, an agent has everything needed to call this correctly on the first attempt.

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

Parameters4/5

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

With 75% schema coverage the schema already carries much of the parameter detail, but the description adds real meaning: the all-day `end` date is INCLUSIVE ('2026-09-01' to '2026-09-03' creates a three-day event), both ends must use the same form, and time_zone governs DST persistence. Some of this duplicates the schema's own descriptions, so it is additive rather than decisive.

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

Purpose5/5

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

States a specific verb and resource ('Creates an event') plus the write-scope constraint ('in one of the calendars this access may write to'). An agent can immediately separate this from update_event, delete_event, and search_events without opening any schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use guidance by naming siblings: call get_availability first when booking a specific day, and list_calendars to find writable calendars. It also states the when-not condition ('calendar_id is only needed when several calendars are writable'), so the agent knows when a parameter can be omitted.

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

All Kalender Sync tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?