Kalender Sync

List calendar syncs

list_syncs

Read-onlyIdempotent

Lists the user's own calendar syncs: which calendars feed which, the state, and where a sync is not running, a documented reason, a next step and, where a page in Kalender Sync completes it, next_step_url. A two-way sync is one entry, not two. Calendar names follow the calendars shared with this access; a calendar outside them is returned with a null id and name rather than the sync being hidden. A sync to another person (kind shared_with_person) never names their calendar. event_colors says whether copies keep their own colors (source), get one color per source calendar (fixed), or none (off). It returns no event titles and costs no credits.

The short ref (sync_1, sync_2, …) is the input for diagnose_sync and set_sync_paused; it is positional, so call list_syncs again if syncs may have changed since. An empty list means the user has no syncs of their own, not that none are possible.

Pausing and resuming work here with set_sync_paused, and a new one-way or two-way sync between two own calendars with preview_sync and create_sync — into calendars released for syncs — and deleting with preview_delete_sync and delete_sync. Changing rules happens in the Kalender Sync app: https://app.kalender-sync.de/dashboard

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`scope`	Yes
`syncs`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 25, 2026

addedOutput schema / properties / syncs / items / properties / event_colors

Added value: +{
+  "enum": [
+    "off",
+    "source",
+    "fixed",
+    "mixed"
+  ],
+  "type": "string"
+}

changedOutput schema / properties / syncs / items / required

Previous value: -[
-  "ref",
-  "sources",
-  "target",
-  "kind",
-  "two_way",
-  "status",
-  "reason",
-  "next_step",
-  "next_step_url"
-]New value: +[
+  "ref",
+  "event_colors",
+  "sources",
+  "target",
+  "kind",
+  "two_way",
+  "status",
+  "reason",
+  "next_step",
+  "next_step_url"
+]

AddedOct 18, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, so the bar is lower, yet the description adds substantial behavior: null id/name for calendars outside the shared set, shared_with_person syncs never expose the other person's calendar, no event titles returned, and no credits consumed. It also warns the short ref is positional and callers should re-list if syncs may have changed.

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?

Dense and front-loaded with the core definition first, then caveats, then sibling routing. Some sentences are convoluted ("where a page in Kalender Sync completes it, next_step_url") and the closing multi-tool paragraph is list-like, but nearly every sentence carries information an agent needs.

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 no-parameter read tool with annotations and an output schema, the description covers what is returned, the edge cases (empty list, null calendar, shared_with_person), the cost model, and which tools consume the returned ref. Nothing material is missing.

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?

Zero parameters, so the baseline is 4. The description goes beyond the schema by explaining the returned field semantics (event_colors source/fixed/off, next_step_url, sync_1 short refs), though an output schema already exists and carries part of that load.

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 (lists the user's own calendar syncs) and immediately scopes it: own syncs only, one entry per two-way sync, no event titles. An agent can distinguish it from list_calendars and from the mutation siblings without opening a 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?

Explicitly routes the agent to alternatives: set_sync_paused for pausing/resuming, preview_sync and create_sync for creating, preview_delete_sync and delete_sync for deleting, and the dashboard for rule changes. It also states a when-not: an empty list means the user has no own syncs, not that none are possible.

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?