Skip to main content
Glama

Delete events

delete_events
Destructive

Delete events or clear whole days — one or many in a single call. Pass ops, an array where each item has an op (delete | clear): delete removes one event by id. A bare series id addresses the whole series; seriesId@YYYY-MM-DD addresses one occurrence; add scope:"future" to an occurrence id for that occurrence and every later one. clear removes everything from from to to (inclusive, equal for one day). By default the whole batch is atomic: if ANY op fails, nothing is removed; pass partial: true for best-effort. Every removal is reversible with the returned undoToken (call undo before expiresAt). Deleting a calendar-linked event also removes it from that calendar; an event marked readOnly can't be deleted this way. A delete result lists deletedIds; a scope:"future" delete also returns the truncated series as updated. To create or edit events use write_events.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
opsYes
renderNoWhen the user is looking at their reassign dial, set true to repaint it with the updated day in this same call. Otherwise the change reaches an open dial only if the host forwards this result.
partialNoBest-effort mode: apply the ops that succeed and report the rest as errors, instead of the default all-or-nothing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • removedInput schema / properties / concise
      Removed value: -{
      -  "description": "Drop the human-readable `suggestedFollowup` prose from the response (the structured `undoToken` is still returned). Saves tokens.",
      -  "type": "boolean"
      -}
    • removedInput schema / properties / ops / items / default
      Removed value: -{
      -  "op": "__invalid__"
      -}
    • changedInput schema / properties / ops / items / oneOf
      Previous value: -[
      -  {
      -    "properties": {
      -      "id": {
      -        "type": "string"
      -      },
      -      "occurrenceDate": {
      -        "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      -        "type": "string"
      -      },
      -      "op": {
      -        "const": "delete",
      -        "type": "string"
      -      },
      -      "scope": {
      -        "enum": [
      -          "all",
      -          "future",
      -          "this"
      -        ],
      -        "type": "string"
      -      }
      -    },
      -    "required": [
      -      "op",
      -      "id"
      -    ],
      -    "type": "object"
      -  },
      -  {
      -    "properties": {
      -      "date": {
      -        "description": "Day to clear, ISO \"YYYY-MM-DD\".",
      -        "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      -        "type": "string"
      -      },
      -      "op": {
      -        "const": "clear",
      -        "type": "string"
      -      },
      -      "to": {
      -        "description": "Optional inclusive range end.",
      -        "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      -        "type": "string"
      -      }
      -    },
      -    "required": [
      -      "op",
      -      "date"
      -    ],
      -    "type": "object"
      -  }
      -]New value: +[
      +  {
      +    "additionalProperties": false,
      +    "properties": {
      +      "id": {
      +        "description": "The event id from a read. A bare series id addresses the whole series; `seriesId@YYYY-MM-DD` addresses one occurrence.",
      +        "minLength": 1,
      +        "type": "string"
      +      },
      +      "op": {
      +        "const": "delete",
      +        "type": "string"
      +      },
      +      "scope": {
      +        "const": "future",
      +        "description": "Only with a `seriesId@YYYY-MM-DD` id: \"future\" edits that occurrence and every later one. Omit it to edit only that occurrence; a bare series id edits the whole series.",
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "op",
      +      "id"
      +    ],
      +    "type": "object"
      +  },
      +  {
      +    "additionalProperties": false,
      +    "properties": {
      +      "from": {
      +        "description": "First day to clear, ISO \"YYYY-MM-DD\".",
      +        "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      +        "type": "string"
      +      },
      +      "op": {
      +        "const": "clear",
      +        "type": "string"
      +      },
      +      "to": {
      +        "description": "Last day to clear (inclusive), ISO \"YYYY-MM-DD\". Equal to `from` for one day.",
      +        "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "op",
      +      "from",
      +      "to"
      +    ],
      +    "type": "object"
      +  }
      +]
  2. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. Changed1 schema field changed
    • addedInput schema / properties / ops / items / default
      Added value: +{
      +  "op": "__invalid__"
      +}
  4. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, and the description adds substantial behavioral context: atomicity by default, partial mode, undoToken reversibility, calendar-linked event behavior, readOnly restriction, and return values. This goes well beyond the annotation.

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 dense but well-structured, front-loading the core action and then systematically covering modes, atomicity, reversibility, edge cases, and alternatives. Every sentence adds value, though it is long and could benefit from slight restructuring.

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?

Given the tool's complexity (two op types, scope semantics, atomicity, undo, calendar integration), the description covers nearly all necessary context. No output schema exists, but the description lists key return fields (deletedIds, updated). Minor gaps like the exact undoToken format are acceptable.

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 67%, and the description adds meaning for the ops parameter by explaining the op types, id formats, scope semantics, and clear range. It also explains partial and render behavior. The description compensates for the schema's gaps, though some details like the exact format of undoToken are not covered.

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 deletes events or clears whole days, with a specific verb and resource. It distinguishes itself from write_events by explicitly saying 'To create or edit events use write_events.'

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 provides explicit when-to-use guidance, including the alternative write_events for creating/editing. It also explains the different modes (delete vs clear) and the partial flag for best-effort, giving clear context for when to use each.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.