Skip to main content
Glama
Sign In
sam2kb

m365-mcp

by sam2kb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

m365_calendar_update

Destructive

Updates selected fields on an existing Microsoft 365 calendar event while preserving omitted fields, so you can change details without recreating the event.

Instructions

Change supplied fields on an existing event; omitted fields stay unchanged. Meeting changes may notify attendees. Body updates replace the notes: first read m365_calendar_get and preserve online-meeting details. Use m365_calendar_create for a new event or m365_calendar_cancel to cancel. Returns success and eventId. Check the event before repeating an update after an uncertain outcome.

Input Schema

NameRequiredDescriptionDefault
endNoNew ISO 8601 end date-time, using the same timezone conventions as start
bodyNoReplacement notes; omit to preserve, or pass an empty string to clear. For online meetings preserve the meeting details in the body.
startNoNew ISO 8601 start date-time; no offset uses the configured timezone; Z/an offset specifies an instant
eventIdYesExisting event ID from m365_calendar_list; must belong to the selected calendar
subjectNoReplacement subject; omit to preserve it
locationNoReplacement location; omit to preserve it or use an empty string to clear it
calendarIdNoOptional mailbox calendar ID matching the event; omit to use the default /me event scope
bodyContentTypeNoFormat of the supplied bodyhtml

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.2.1
    • changedInput schema / properties / calendarId / description
      Previous value: -"Optional calendar ID for a specific calendar"New value: +"Optional mailbox calendar ID matching the event; omit to use the default /me event scope"
    • changedInput schema / properties / end / description
      Previous value: -"New end time (ISO 8601)"New value: +"New ISO 8601 end date-time, using the same timezone conventions as start"
    • changedInput schema / properties / eventId / description
      Previous value: -"Event ID"New value: +"Existing event ID from m365_calendar_list; must belong to the selected calendar"
    • changedInput schema / properties / location / description
      Previous value: -"New location"New value: +"Replacement location; omit to preserve it or use an empty string to clear it"
    • changedInput schema / properties / start / description
      Previous value: -"New start time (ISO 8601)"New value: +"New ISO 8601 start date-time; no offset uses the configured timezone; Z/an offset specifies an instant"
    • changedInput schema / properties / subject / description
      Previous value: -"New subject"New value: +"Replacement subject; omit to preserve it"
  2. Changed3 schema fields changedv1.2.0
    • changedInput schema / properties / body / description
      Previous value: -"New description"New value: +"Replacement notes; omit to preserve, or pass an empty string to clear. For online meetings preserve the meeting details in the body."
    • addedInput schema / properties / bodyContentType
      Added value: +{
+  "default": "html",
+  "description": "Format of the supplied body",
+  "enum": [
+    "text",
+    "html"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / calendarId
      Added value: +{
+  "description": "Optional calendar ID for a specific calendar",
+  "minLength": 1,
+  "type": "string"
+}
  3. First observedv1.0.7

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true, idempotentHint=false, and openWorldHint=true; the description goes beyond them by disclosing attendee notification side effects, that body updates replace rather than append notes, and that online-meeting details must be preserved by reading first. These are non-obvious mutation behaviors an agent could not infer from annotations alone.

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?

Five short sentences, each carrying distinct information: patch semantics, side effects, body-replacement hazard, sibling routing, and return/retry behavior. The core contract is front-loaded in the first clause with no filler.

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?

There is no output schema, and the description compensates by stating the return shape ('success and eventId'). Combined with annotations covering the safety profile and a 100%-covered input schema, an agent has everything needed to invoke this correctly and handle uncertain outcomes.

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 per-field replacement/clear semantics are already documented; the description reinforces the omit-preserves rule and elevates the body-replacement caveat about online-meeting details. It adds cohesion and a warning beyond the schema, though most field-level detail is duplicate.

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 ('Change supplied fields on an existing event') and immediately clarifies the patch semantics ('omitted fields stay unchanged'). It distinguishes itself from m365_calendar_create, m365_calendar_cancel, and m365_calendar_get by name, so an agent can route without opening schemas.

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 names alternatives and the conditions selecting them: create for new events, cancel to cancel, get to read before a body update. It also gives a retry guardrail ('Check the event before repeating an update after an uncertain outcome'), which is exactly the when/when-not guidance the dimension asks for.

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

Deploy Server

Other Tools