Skip to main content
Glama

Microsoft 365 Delete Event

m365_delete_event
Destructive

Deletes an event from the connected Microsoft 365 / Outlook calendar by its id (from m365_list_events). If the user organizes the meeting and it has attendees, Microsoft 365 sends them a cancellation. For a recurring event the id from m365_list_events is the whole series: deleting it removes every occurrence. When the user organizes it and it has attendees (a cancellation would be emailed), the first call deletes nothing and previews the event: subject, date, attendees, and whether the id is a whole recurring series; call again with confirm=true after the user approves. Any other event is deleted on the first call (it goes to Deleted Items). For the Mac's Calendar app use delete_calendar_event instead.

Input Schema

NameRequiredDescriptionDefault
idYesEvent ID from m365_list_events
accountNoWhich connected Microsoft 365 account to use: its email (UPN), its id from list_m365_accounts, or its display name when unique. Leave it out to use the default account.
confirmNotrue after the user approved deleting a meeting they organize with attendees (it emails a cancellation).
rememberNoWith confirm: true, also stop asking for this kind of action from now on. Only when the person said so ("don't ask again"). The person can revoke it in LMCP or with set_always_allowed.

Output Schema

NameRequiredDescriptionDefault
okNo
accountNoThe email (UPN) of the Microsoft 365 account this call used.
messageNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / confirm / description
      Previous value: -"Set to true to confirm deletion (required)"New value: +"true after the user approved deleting a meeting they organize with attendees (it emails a cancellation)."
    • addedInput schema / properties / remember
      Added value: +{
      +  "description": "With confirm: true, also stop asking for this kind of action from now on. Only when the person said so (\"don't ask again\"). The person can revoke it in LMCP or with set_always_allowed.",
      +  "type": "boolean"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "id",
      -  "confirm"
      -]New value: +[
      +  "id"
      +]
  2. Changed2 schema fields changed
    • addedInput schema / properties / account
      Added value: +{
      +  "description": "Which connected Microsoft 365 account to use: its email (UPN), its id from list_m365_accounts, or its display name when unique. Leave it out to use the default account.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / account
      Added value: +{
      +  "description": "The email (UPN) of the Microsoft 365 account this call used.",
      +  "type": "string"
      +}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructiveHint/openWorldHint, but the description adds what they cannot: attendee cancellation emails are sent, a recurring id wipes every occurrence, the two-phase preview/confirm flow, and that deleted events land in Deleted Items. This is exactly the side-effect detail an agent needs before mutating.

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 and scoped sharply, but the organizer-with-attendees condition is stated twice (once for the cancellation email, once for the preview behavior), costing a sentence of redundancy in an otherwise tight paragraph.

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?

Output schema exists so return values need no explanation; all four params are documented; the destructive path, recurrence semantics, and the sibling alternative are all covered. An agent has everything needed to call this safely.

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%, so the baseline is 3; the description goes further by explaining that the id from m365_list_events represents an entire series for recurring events, which changes what 'delete' costs. The confirm gate is restated, which is redundant with the schema but harmless.

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 and resource ('Deletes an event from the connected Microsoft 365 / Outlook calendar') plus the source of the identifier. The final sentence explicitly routes away from delete_calendar_event, so an agent can distinguish it from siblings without opening a schema.

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?

Explicitly gives a conditional workflow: organizer-with-attendees requires a preview call then confirm=true; anything else deletes immediately. It also names the alternative ('For the Mac's Calendar app use delete_calendar_event instead'), covering when-not territory.

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.

Resources