Kalender Sync

Preview deleting a calendar sync

preview_delete_sync

Read-onlyIdempotent

Shows what deleting one of the user's own syncs would do, without deleting anything: which calendars it connects and exactly how many copies it has written that would be removed from the target calendar(s). Tell the user this in plain words and ask them to confirm. It returns a confirmation_token, valid for 10 minutes and only for this sync, which delete_sync requires.

Only syncs whose target calendars are released for syncs (sync_target) can be deleted here; a sync with another person is managed in the app. Use a ref from a current list_syncs result. Costs no credits.

Input Schema

Name	Required	Description	Default
`ref`	Yes	A ref from a current list_syncs result, e.g. sync_2

Output Schema

Name	Required	Description	Default
`sync`	Yes
`expires_at`	Yes
`copies_to_remove`	Yes
`confirmation_token`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 25, 2026

addedOutput schema / properties / sync / properties / event_colors

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

changedOutput schema / properties / sync / 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?

Beyond the readOnly/non-destructive annotations, it discloses the confirmation_token lifetime (10 minutes), that the token is scoped to this specific sync, that delete_sync requires it, and that the call costs no credits. These are exactly the behavioral details an agent needs to avoid misusing the preview.

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?

The description is front-loaded with the key non-destructive purpose and confirmation workflow. It is somewhat longer than strictly necessary for a one-parameter tool, but nearly every sentence carries actionable information such as token scope, eligibility, and cost.

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?

Given the output schema, annotations, and single fully documented parameter, the description covers everything needed: purpose, confirmation workflow, token dependency, eligibility limits, and credit cost. Nothing material is missing for correct invocation.

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?

Schema coverage is 100% and the schema already explains that ref comes from list_syncs. The description adds useful semantics by restricting valid refs to the user's own deletable syncs whose target calendars are released for syncs.

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 gives a specific verb and resource ('Shows what deleting one of the user's own syncs would do') and immediately clarifies it is a non-destructive preview. It also states the concrete payload (connected calendars, number of copies that would be removed), which distinguishes it cleanly from delete_sync.

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?

It states the workflow explicitly: show the preview to the user in plain words, ask for confirmation, then call delete_sync with the token. It also says when this tool is not usable (syncs with another person are managed in the app) and where to get the required ref (a current list_syncs result).

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?