MCP field guide / Google Calendar
// mcp field guide · productivity
A quietly consequential one. Reading your calendar is harmless — but creating, updating, or deleting an event with attendees emails real people, and that invite or cancellation can't be un-sent. The calendar row is trivially editable afterward; the notification isn't. So, like Slack, the irreversible part is the email, not the data.
GUARD FIT · READS + SOLO EVENTS
PASS-THROUGHList/search events, check free/busy, and no-attendee personal events — no external side effect.
GUARD FIT · EVENTS WITH ATTENDEES
MODERATECreate/update/delete an invited event emails real attendees; the invite/reschedule/cancellation can't be recalled.
Overall fit: MODERATE — proportional to how many real recipients an operation touches; lower stakes than money.
Official — Google Calendar MCP (hosted, calendarmcp.googleapis.com, Developer Preview), inheriting the signed-in user's OAuth scopes. Community — nspady/google-calendar-mcp (npm @cocal/google-calendar-mcp, MIT, ~1.2k stars, local) — the long-standing default for local setups, adding multi-account and free/busy conflict detection.12 Both run under the user's own Calendar scopes.
Official uses _ names; community uses - names. The "consequential" tier is the same create/update/delete tools — the risk is the email side effect, not a separate tool.
| Tier | Tools |
|---|---|
| read-only | list_calendars, list_events, get_event, search_events, suggest_time (official); get-freebusy, list-colors (community) |
| mutating | create_event, update_event, respond_to_event (RSVP) — harmless when the event has no attendees |
| notifies real people | create_event with attendees (sends invites), update_event on an invited event (sends "updated" emails), delete_event on an invited event (sends cancellations) — irreversible notifications |
The suppression knob is unverified. Google's REST API has a sendUpdates parameter (all/externalOnly/none) to control whether invite/update/cancel emails go out — but whether either MCP tool exposes send-suppression is not documented on the tool references we could read. The email-on-attendee-change behavior itself is verified; the knob to suppress it is not. So assume the notification fires.
Availability. "What's on my calendar next week / when am I free Thursday?" — reads + free/busy.
Scheduling. "Schedule a 30-min sync with alice@ and bob@ tomorrow at 2pm" — create_event with attendees, emailing invites.
Rescheduling. "Move the Friday review to Monday and cancel the duplicate hold" — update_event + delete_event, both notifying attendees.
Reads and solo events → pass through. Listing, searching, checking free/busy, and personal no-attendee events have no external side effect and don't warrant a gate.
Events with attendees → moderate, and the framing is Slack-like. A wrong invite, a mistimed reschedule, or a bad cancellation emails real humans and can't be un-sent — even though the calendar entry itself is trivially editable afterward. Gate create_event/update_event with a non-empty attendee list and delete_event for events that have attendees; a diff showing recipients + time is the useful signal. Bulk changes (an agent cancelling or moving many invited events in a loop) amplify the blast radius and are a stronger trigger.
Honest calibration: lower stakes than money — no funds move; worst case is scheduling noise and a confused attendee. The compensation asymmetry is the point: you can delete the erroneously-created event, but the invite email already landed. Compensation is not undo, in its most everyday form — and a guard's value is proportional to how many real recipients an operation touches.
ChronoMCP passes reads and solo events through, and holds create/update/delete-with-attendees for a human — showing who gets emailed.
Read the quickstart → More MCP profilesnspady/google-calendar-mcp (MIT, local): github.com/nspady/google-calendar-mcpProfiles describe third-party software from its public sources; ChronoMCP is not affiliated with Google, and the community server is an independent project. The attendee-email behavior is verified; whether the MCP tools expose a sendUpdates-style suppression parameter is unverified. Risk groupings are our classification. Sources current as of Aug 2026 (the official server is in Developer Preview) — check the source links.