Skip to main content
Glama
conorbronsdon

Google Workspace (GWS) MCP Server

by conorbronsdon
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

calendar_events_update

Update an existing Google Calendar event by changing its title, time, description, or attendee list, and optionally notify attendees via email.

Instructions

Update an existing calendar event with patch semantics (only supplied fields change).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endNoEnd time JSON
startNoStart time JSON
eventIdYesEvent ID to update
summaryNoEvent title
attendeesNoREPLACES the full attendee list — Google's patch overwrites array fields, so include everyone who should remain; anyone omitted is uninvited. JSON array as string, e.g. '[{"email":"a@x.com"},{"email":"b@x.com","optional":true}]'
calendarIdYesCalendar ID
descriptionNoEvent description
sendUpdatesNoSends update email to attendees when set: "all", "externalOnly", or "none" (default: none — no email). With "all" or "externalOnly", attendees removed by this update receive a cancellation email

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.4.1
    • addedInput schema / properties / attendees
      Added value: +{
+  "description": "REPLACES the full attendee list — Google's patch overwrites array fields, so include everyone who should remain; anyone omitted is uninvited. JSON array as string, e.g. '[{\"email\":\"a@x.com\"},{\"email\":\"b@x.com\",\"optional\":true}]'",
+  "type": "string"
+}
    • addedInput schema / properties / sendUpdates
      Added value: +{
+  "description": "Sends update email to attendees when set: \"all\", \"externalOnly\", or \"none\" (default: none — no email). With \"all\" or \"externalOnly\", attendees removed by this update receive a cancellation email",
+  "enum": [
+    "all",
+    "externalOnly",
+    "none"
+  ],
+  "type": "string"
+}
  2. First observedv1.0.0

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already establish readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the description's main addition is the patch-semantics disclosure: 'only supplied fields change.' That is a useful behavioral trait, but the description does not mention significant side effects such as attendee-list replacement or update-email behavior, which are relevant for a mutation tool. No contradiction exists between the description and annotations.

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?

A single sentence that is front-loaded with the operation and resource and conveys the key semantic in a short parenthetical. There is no filler, repetition, or duplication of schema content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The schema is rich and covers parameter meanings, required fields, enum values, and the sensitive attendees-overwrite behavior, so an agent can construct a correct call. However, the description itself is minimal: it does not describe the response (no output schema), permissions, or side effects such as the sendUpdates default, leaving an agent to rely entirely on schema details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 8 parameters have schema descriptions (100% coverage), including a detailed warning about attendees replacement, so the schema carries the parameter-level burden. The description only adds the general patch rule 'only supplied fields change,' which contextualizes optionality but does not explain any specific parameter.

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 leads with the verb 'Update' and identifies the exact resource, 'existing calendar event,' so an agent knows immediately this modifies an event rather than listing, creating, or deleting it. Adding 'patch semantics' further distinguishes this from a full-replacement update and from sibling operations such as calendar_events_insert or calendar_events_delete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly situates the tool as the update operation for already-created events ('existing calendar event'), implying it should not be used for creation or deletion. It does not explicitly name alternatives or list exclusions, so it falls slightly short of full routing guidance.

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