For developers: tool reference
The Kalender Sync MCP server (https://app.kalender-sync.de/mcp, Streamable HTTP) exposes up to seven tools.
Two properties apply to every tool:
- Visibility gating: each tool only sees the calendars you shared, and per calendar only the allowed detail level. Calendars you did not share do not exist for the server.
- Dynamic tool list: the three write tools only appear when your access may write (granted per calendar). A read-only access sees 4 tools — we don’t ship tools that would always refuse. If you change write permissions later, the tools only show up once the client reloads the tool list.
Read tools
Section titled “Read tools”list_calendars
Section titled “list_calendars”Lists the shared calendars with their detail level. readable: false marks calendars that can’t be read right now (they are then missing from every other answer too — and are deliberately listed rather than omitted). writable: true marks the calendars this access may create events in — that is where the calendar_id for create_event comes from. sync_health additionally shows the state of Kalender Sync’s own synchronisation of that calendar, if it takes part in one.
Parameters: none.
get_availability
Section titled “get_availability”Returns busy times in a range, across all shared calendars. Every calendar is read directly at the provider (no copy); reads are reused for up to 60 seconds. Included is everything that blocks time — all-day events and “tentative” ones too. Not included: cancelled events and events explicitly marked “free”. If a calendar could not be read, that appears in sources and warnings — an answer never claims a completeness it doesn’t have.
| Parameter | Required | Description |
|---|---|---|
from / to | yes | Range, ISO 8601. Max span 92 days, lookback bounded to 365 days. |
search_events
Section titled “search_events”Finds events by text — case-insensitive substring over title, location and description. The search is deliberately a filter over the same visibility-rendered data get_availability returns, not a second read path: calendars on the “busy only” level carry no titles and therefore can never match — the answer says so as a warning. “No match” is never proof that the event doesn’t exist.
| Parameter | Required | Description |
|---|---|---|
query | yes | Search text (min. 2 characters) |
from / to | no | Range as in get_availability; default −7 to +85 days |
At most 50 matches (the chronologically earliest), truncated signals when the cap was hit.
send_feedback
Section titled “send_feedback”Sends the user’s feedback to the Kalender Sync team — for example when they wanted something the tools can’t do yet. The assistant is instructed to use this only on the user’s explicit request. contact_ok (default: off) permits exactly one topical reply from us — no newsletter, no mailing list. Processing details in the privacy policy, section 3.10.
| Parameter | Required | Description |
|---|---|---|
message | yes | The feedback (10–2000 characters) |
category | yes | missing_capability · bug · other |
contact_ok | no | Only if the user explicitly agreed to a single reply |
Write tools (all plans, granted per calendar)
Section titled “Write tools (all plans, granted per calendar)”The central principle: the assistant can only touch events it created itself. Your existing events are technically not addressable for it — that’s architecture, not a rule a prompt could break. More under write access.
create_event
Section titled “create_event”Creates an event in a writable calendar. Availability is checked live at write time (not from cache): an overlap does not prevent creation but comes back as a warning — whether to double-book is the user’s call. start/end require ISO 8601 with a timezone; calendar_id is only needed with several writable calendars — list_calendars shows which those are via writable: true. If it is omitted with several, the error message names the permitted calendars.
update_event · delete_event
Section titled “update_event · delete_event”Update or delete an event this access created itself (via the event_id from create_event). Foreign events are not addressable — the server answers not_found, not forbidden, so it doesn’t even confirm existence. Deletions are executed at the provider and propagate into mirrored calendars through the normal sync. Both tools carry the MCP annotation destructiveHint: true.
Logging
Section titled “Logging”Every tool call lands in the access log as metadata — timestamp, tool, calendars concerned, outcome. Never the content of your events, never the search text, never the feedback wording.
As of server version 1.2.0 (2026-07-31). The server is listed in the official MCP Registry as de.kalender-sync/kalender-sync. It rebuilds the tool list on every connection, but clients cache it — after a permission change you have to reload it in your client.