Skip to main content
Glama
Sign In

Multi Calendar

by co.lumman
OverviewDiscussionsAdmin

Cancel an event

events_cancel
DestructiveIdempotent

Cancel or call off an event the account organises; its provider sends a meeting's attendees the cancellation from that account's own address - Apple from its own address under the person's name, and a calendar server from the account's own address, to every guest, where it says it sends cancellations itself, a meeting with guests refused elsewhere - as notify chooses, and Outlook sends message with it. Someone else's event is not cancelled here: declining it with events_respond takes it off an Outlook calendar and leaves it on a Google one, shown declined. copyOnly true takes only the account's own copy of someone else's event off its calendar - an Outlook copy its organiser has cancelled included - sending nothing, though Google then shows the account as declined and so needs inviting and replying allowed.

Input Schema

NameRequiredDescriptionDefault
scopeNoFor an occurrence of a recurring series: occurrence, where omitted, acts on that occurrence alone, series on its whole series. A series named by its own seriesId is refused unless series is passed.
notifyNoWho the provider tells: every guest where omitted, externalOnly only guests outside Google Calendar, none nobody. Outlook tells every guest of a meeting it makes, changes or cancels, so there only an answer goes untold.
accountYesThe connected account, by the address calendars_list names.
eventIdYesThe event's id, as events_list names it.
messageNoWords sent to the guests with the cancellation; Outlook alone sends them.
copyOnlyNoTrue to take only the account's own copy of someone else's event off its calendar; the event stands for everyone else.
providerNoThe account's provider, as calendars_list names it; needed only where two connected accounts share an address.
calendarIdNoThe calendar holding the event, by the calendarId events_list names; a Google account's event outside its default calendar needs it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / provider / enum
      Previous value: -[
-  "google",
-  "microsoft",
-  "icloud"
-]New value: +[
+  "google",
+  "microsoft",
+  "icloud",
+  "caldav"
+]
  2. Changed1 schema field changed
    • changedInput schema / properties / provider / enum
      Previous value: -[
-  "google",
-  "microsoft"
-]New value: +[
+  "google",
+  "microsoft",
+  "icloud"
+]
  3. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Beyond the annotations, the description explains that cancellations notify attendees from the account's own address, that Outlook sends the optional message, and that copyOnly sends nothing. These are meaningful behavioral disclosures for a destructive mutation tool. The provider-specific wording is convoluted and leaves some edge cases hard to parse, so it is not fully transparent.

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

Conciseness2/5

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

The description is a single sprawling run-on sentence with nested clauses and semicolons, making it difficult to scan. While many details are relevant, they are not front-loaded or organized into digestible statements. This is a structural weakness, not merely a length issue.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex destructive tool with eight parameters and no output schema, the description covers the key semantic branches: normal cancellation, events_respond for someone else's event, and copyOnly for local removal. Annotations already cover safety and idempotency. The missing return-value detail is minor for a cancel operation, though the confusing wording slightly reduces completeness.

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 description coverage is 100%, so all eight parameters are already documented in the input schema. The description reinforces notify, message, and copyOnly behavior, but adds little syntax or meaning beyond the schema's existing descriptions. Baseline 3 is appropriate when the schema carries the parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Cancel or call off an event the account organises.' It also distinguishes the tool from events_respond by explaining that someone else's event is not cancelled here. However, the purpose is buried inside a long run-on sentence with provider-specific details, which reduces immediate clarity.

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 explicitly says when not to use this tool: 'Someone else's event is not cancelled here: declining it with events_respond takes it off an Outlook calendar and leaves it on a Google one.' It also names copyOnly as the alternative path for removing only the account's own copy of someone else's event, giving clear routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Multi Calendar toolsInspect
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