What Does a Calendar MCP Event Patch Actually Change?

update_event sends a partial Google Calendar PATCH. Leaving a field out keeps its existing value. Supplying attendees, however, replaces the attendee array. That distinction matters when an agent says "just add Priya."

The boundary in the implementation

CalendarMCP builds the request body only from fields supplied by the caller and sends it to events.patch. An omitted summary or locationis left unchanged. If the caller supplies attendees, the tool maps that entire input list to Google attendee objects. Google's PATCH reference says specified arrays overwrite their old contents. A one-address array is not an instruction to append one guest.

Consider a hypothetical event with Lee and Priya invited. A patch with onlysummary: "Design review" does not change those guests. A patch withattendees: ["new@example.com"]replaces the list, potentially dropping Lee and Priya. That is why a proposed guest edit needs a before-and-after list, not a vague "updated attendees" confirmation.

Choose the narrow operation

For a title or location change, pass only that field with the exact calendarIdand eventId. For guest changes, first read the event, then usemanage_attendees for explicit add/remove operations or provide the complete intended attendee set to update_event. Review the guest list again before committing. Service-account connections to personal calendars cannot use the attendee editing path in CalendarMCP; the tool returns an error rather than silently dropping it.

A PATCH is not a concurrency lock. CalendarMCP's formatted get_eventresult does not expose an ETag for conditional writes, so another editor could change the event between your read and patch. Coordinate high-stakes edits outside the agent if concurrent writers are likely. The tool docs show the available inputs; they do not promise atomic multi-editor conflict handling.