Kalender Sync

Delete event

delete_event

Destructive

Deletes an event. The deletion is executed at the provider and propagates into any mirrored calendars through the normal sync.

Addressable are events THIS access created, and — where the user allowed managing (manageable: true in list_calendars) — any other event in that calendar.

Deleting is the irreversible one: confirm with the user first when the event is not one this access created, and say what it is (title and time) so they can recognise it. When the event has other participants, deleting it as the organiser cancels it for them too — mention that before doing it.

The same four refusals as update_event apply, each naming the way forward. For an invitation someone else organised, respond_to_event is the right tool: deleting it would only hide it locally and leave the organiser expecting the user.

Check status first: credits_exhausted means this call was NOT performed. Only warnings and credit information are returned in that case; no result data or write confirmation. Tell the user how to restore credits; do not retry automatically.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`event_id`	Yes	Identifier from create_event
`calendar_id`	No

Output Schema

TableJSON Schema

Name	Required	Description
`status`	Yes	ok: tool executed; use its result fields. credits_exhausted: not executed; no result fields.
`deleted`	No
`event_id`	No
`warnings`	No
`resets_at`	No
`calendar_id`	No
`credits_required`	No
`credits_available`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 11, 2026

addedOutput schema / properties / credits_available
```
Added value: +{
+  "type": "number"
+}
```
addedOutput schema / properties / credits_required
```
Added value: +{
+  "type": "number"
+}
```

addedOutput schema / properties / resets_at

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / status

Added value: +{
+  "description": "ok: tool executed; use its result fields. credits_exhausted: not executed; no result fields.",
+  "enum": [
+    "ok",
+    "credits_exhausted"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / warnings

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

changedOutput schema / required

Previous value: -[
-  "event_id",
-  "calendar_id",
-  "deleted"
-]New value: +[
+  "status"
+]

First observedJul 31, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already flag destructive and openWorld, but the description adds substantial context beyond them: provider-level propagation to mirrored calendars, irreversibility, cascade cancellation for co-participants, shared refusal semantics with update_event, and the credits_exhausted non-execution contract (no result data, do not retry). This is exactly the behavioral disclosure a destructive tool needs.

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 action, then builds outward to scope, confirmation duties, and error semantics. Dense and largely waste-free, though the middle paragraphs are prose-heavy enough that an agent must read carefully to extract the actionable rules.

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-format details are not required, yet the description still covers the critical conditional return case (credits_exhausted yields no write confirmation). Combined with the addressability rules and refusal/alternative routing, nothing an agent needs to call this safely is missing.

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

Parameters3/5

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

Schema coverage is 50%: event_id is documented as coming from create_event, but calendar_id has no description in either the schema or the prose. The description clarifies which events are addressable, which implicitly constrains the calendar scope, but does not explain the calendar_id parameter itself. Baseline 3 for a partially documented 2-param tool.

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+resource ('Deletes an event') and immediately clarifies scope: deletion happens at the provider and propagates through sync. It explicitly distinguishes itself from siblings by naming respond_to_event as the correct tool for invitations organised by others.

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/when-not conditions: only events THIS access created unless manageable:true, confirm with the user first for events not created by this access, warn participants are cancelled along with the deletion. Names the alternative (respond_to_event) and the fallback behaviour of update_event refusals.

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?