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.

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

TDQS

A4.8/5.0

Behavior5/5

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

This description goes well beyond annotations by exposing live availability checking, non-blocking behavior for overlaps, the warning return, all-day end-date inclusivity, rejection of timestamp without timezone, and DST behavior via time_zone. These are exactly the non-obvious behaviors an agent needs to handle correctly.

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

Conciseness5/5

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

The description is long but every sentence carries operational value. Important edges are highlighted in bold and front-loaded, with practical examples and clear guidance, so the length is justified and easy to scan.

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?

For a tool with 8 parameters, an output schema, and several subtle interactions (all_day, time_zone, calendar_id, overlap warnings), the description covers all critical behavioral corners. The existing output schema handles return details, so no further description is needed.

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

Parameters5/5

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

Although schema coverage is at 75%, the description adds meaningful semantics: it explains the date-string forms for all-day events, the inclusive end requirement, and the exact conditions for supplying calendar_id. It also provides a concrete example that clarifies how all-day dates are interpreted.

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?

The description starts with 'Creates an event in one of the calendars this access may write to', naming a specific verb and resource. It clearly distinguishes creation from siblings like update_event, delete_event, and search_events by stating the action and its target.

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

Usage Guidelines4/5

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

The description explains when calendar_id is needed and references list_calendars for discover writable calendars, which gives concrete usage context. It does not explicitly mention when to prefer update_event or get_availability, but the creation intent and prerequisite awareness are clear.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Each tool targets a distinct action or resource: create/update/delete events, availability lookup, calendar listing, text search, and feedback. Even closely related read tools like get_availability and search_events are clearly separated by their purpose and output.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern: create_event, delete_event, get_availability, list_calendars, search_events, send_feedback, update_event. There are no mixed conventions or vague generic verbs.

Tool Count5/5

Seven tools is well-scoped for a calendar integration server, covering the core calendar operations plus a feedback channel. Each tool has a clear purpose and none feel redundant or unnecessary.

Completeness4/5

The surface covers the main calendar lifecycle: create, update, delete, availability, listing, and search. Minor gaps exist such as no direct get_event-by-id operation and no invite/RSVP handling, but these are acknowledged limitations rather than severe dead ends.

Resources

Need Help?