Skip to main content
Glama

Cancel recurring meeting occurrence

cancel_recurring_meeting_occurrence
DestructiveIdempotent

Cancel a single occurrence of a recurring meeting series to skip one slot without affecting the schedule. Requires confirmation and the exact start time from the occurrence list.

Instructions

Cancel one occurrence of a series — skip a slot without touching the schedule.

Use it for "no sync next Monday": the slot stays in the occurrences list as 'cancelled' (backed by a cancelled stub meeting) while the series keeps running. A cancelled occurrence is recoverable — init_recurring_meeting_occurrence at the same instant restores it to 'open' — but the cancellation itself may email participants when the series has notify set, which is why it is confirm-gated.

Returns a small confirmation object carrying the normalized instant.

Pitfalls. The instant is matched exactly and never validated against the schedule: cancelling at a wrong time succeeds (204) by creating a cancelled phantom stub while the real occurrence lives on — always copy start_time from get_recurring_meeting's occurrences. A conflict error (409) means the occurrence is already instantiated as a live meeting, which OpenProject refuses to cancel in place: delete_meeting(meeting_id=...) (the id is in the occurrences row) is the move then. Cancelling an already-cancelled slot is an idempotent success. This needs the 'edit meetings' permission.

Cross-references: get_recurring_meeting for the exact start_time and the occurrence's meeting_id; delete_meeting for an instantiated occurrence; delete_recurring_meeting to end the whole series.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
confirmNoMust be true. Ask the user to confirm first. Calling with confirm=false returns a confirmation_required error rather than cancelling anything.
start_timeYesThe occurrence's scheduled instant, copied VERBATIM from a get_recurring_meeting occurrences row ('2026-08-12T10:00:00Z'). Matching is exact-instant — a wrong time cancels a phantom stub while the real occurrence lives on.
recurring_meeting_idYesNumeric series id from list_recurring_meetings. Never a meeting id.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
messageYesHuman-readable confirmation naming what was cancelled.
cancelledYesTrue once OpenProject accepted the cancellation.
start_timeYesThe cancelled instant, normalized to the canonical UTC 'Z' form.
recurring_meeting_idYesSeries the occurrence belongs to.
Behavior5/5

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

The description goes far beyond the annotations by detailing side effects (may email participants with `notify` set), recovery semantics, exact-instant matching pitfalls, conflict error meaning, idempotent success, and required permissions. This fully discloses the operational behavior.

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

Conciseness5/5

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

The description is dense yet well-organized: opening summary, use case, pitfalls, and cross-references. Every sentence adds meaningful detail; no filler words. It front-loads the core purpose and then layers nuance logically.

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?

The description covers permission requirements, error semantics, idempotency, side effects, recoverability, and exactly references related tools. With an output schema present, the return confirmation is briefly described without over-explaining. Nothing is missing.

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

Parameters5/5

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

Even though schema coverage is 100%, the description enriches each parameter with critical context: `start_time` must be copied verbatim, exact matching is required, and wrong times create phantom stubs. `recurring_meeting_id` is explicitly distinguished from a meeting id. This adds real value beyond the schema.

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 clearly states the tool cancels one occurrence of a series, distinguishing it from deleting the entire series. It explicitly contrasts with `delete_recurring_meeting` (end series) and `delete_meeting` (instantiated occurrence), making the purpose unambiguous.

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?

The description gives concrete use cases ('no sync next Monday'), explicitly names alternatives (`init_recurring_meeting_occurrence`, `delete_meeting`, `delete_recurring_meeting`), and provides fallback behavior for conflict errors. This is exemplary guidance on when to use this tool vs. siblings.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kar-thik/openproject-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server