grr

Overview Schema Source Related Servers Discussions Admin

calendar.calendars.update

Updates an existing calendar's metadata such as summary, description, location, and time zone. Send a JSON Calendar object via params or body_file to apply changes with an HTTP PUT request.

Instructions

Updates metadata for a calendar [HTTP PUT] — updates the resource; refused under --readonly safety profiles. Returns the API's response resource as JSON — request body is a JSON Calendar object accepting autoAcceptInvitations, conferenceProperties, dataOwner, description, etag, id, kind, labelProperties and 3 more fields; pass it via params or whole via body_file Siblings over the same resource: clear, delete, get, insert, patch, transferOwnership.

Input Schema

Name	Required	Description
`query`	No	Extra KEY=VALUE query pairs for endpoints whose parameters Discovery does not describe.
`params`	No	Parameter map merged into the request; typed parameters win.
`dry_run`	No	Return the request that would be sent, without sending it.
`body_file`	No	Read the request body from this file ('-' for stdin) instead of building one from the parameters. The body is a JSON Calendar object.
`calendarId`	Yes	[URL path segment] Calendar identifier. To retrieve calendar IDs call the calendarList.list method. If you want to access the primary calendar of the currently logged in user, use
`request_body`	No	Request body of type Calendar: pass it via `params` (merged into the built body) or whole via `body_file`.

Output Schema

Name	Required	Description	Default
`id`	No
`etag`	No
`kind`	No
`summary`	No
`location`	No
`timeZone`	No
`dataOwner`	No
`description`	No
`labelProperties`	No
`conferenceProperties`	No
`autoAcceptInvitations`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 26, 2026

changedInput schema / properties / body_file / description

Previous value: -"Read the request body from this file ('-' for stdin) instead of building one from the parameters."New value: +"Read the request body from this file ('-' for stdin) instead of building one from the parameters. The body is a JSON Calendar object."

addedInput schema / properties / request_body

Added value: +{
+  "description": "Request body of type Calendar: pass it via `params` (merged into the built body) or whole via `body_file`.",
+  "properties": {
+    "autoAcceptInvitations": {
+      "type": "boolean"
+    },
+    "conferenceProperties": {
+      "properties": {
+        "allowedConferenceSolutionTypes": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        }
+      },
+      "type": "object"
+    },
+    "dataOwner": {
+      "type": "string"
+    },
+    "description": {
+      "type": "string"
+    },
+    "etag": {
+      "type": "string"
+    },
+    "id": {
+      "type": "string"
+    },
+    "kind": {
+      "type": "string"
+    },
+    "labelProperties": {
+      "properties": {
+        "eventLabels": {
+          "items": {
+            "properties": {
+              "backgroundColor": {
+                "type": "string"
+              },
+              "id": {
+                "type": "string"
+              },
+              "name": {
+                "type": "string"
+              }
+            },
+            "type": "object"
+          },
+          "type": "array"
+        }
+      },
+      "type": "object"
+    },
+    "location": {
+      "type": "string"
+    },
+    "summary": {
+      "type": "string"
+    },
+    "timeZone": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changed2 schema fields changedOct 26, 2026

changedInput schema / properties / calendarId / description

Previous value: -"Calendar identifier. To retrieve calendar IDs call the calendarList.list method. If you want to access the primary calendar of the currently logged in user, use"New value: +"[URL path segment] Calendar identifier. To retrieve calendar IDs call the calendarList.list method. If you want to access the primary calendar of the currently logged in user, use"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "autoAcceptInvitations": {
+      "type": "boolean"
+    },
+    "conferenceProperties": {
+      "properties": {
+        "allowedConferenceSolutionTypes": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        }
+      },
+      "type": "object"
+    },
+    "dataOwner": {
+      "type": "string"
+    },
+    "description": {
+      "type": "string"
+    },
+    "etag": {
+      "type": "string"
+    },
+    "id": {
+      "type": "string"
+    },
+    "kind": {
+      "type": "string"
+    },
+    "labelProperties": {
+      "properties": {
+        "eventLabels": {
+          "items": {
+            "properties": {
+              "backgroundColor": {
+                "type": "string"
+              },
+              "id": {
+                "type": "string"
+              },
+              "name": {
+                "type": "string"
+              }
+            },
+            "type": "object"
+          },
+          "type": "array"
+        }
+      },
+      "type": "object"
+    },
+    "location": {
+      "type": "string"
+    },
+    "summary": {
+      "type": "string"
+    },
+    "timeZone": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedOct 26, 2026

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries the load and does well: it declares PUT/full-resource update semantics, discloses the --readonly refusal behavior, and states it returns the API's response resource as JSON. Missing only finer traits like permission requirements or how unspecified fields are handled on a PUT.

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-loads the purpose and verb, then behavior, body details and siblings in a sensible order. It is dense and comma-heavy in the body-field sentence, but every clause carries information.

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

Completeness4/5

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

For a mutation tool with no annotations and a nested request body, the description covers mutation semantics, readonly refusal, body routing and returns; the output schema absolves it of explaining return values. Only the update-vs-patch decision is left unaddressed.

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?

Schema coverage is 100% and the schema already documents query, params, body_file, dry_run and calendarId. The description adds only the mapping of the Calendar body fields and the params-vs-body_file choice, both of which the schema already spells out; baseline 3 applies.

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 ('Updates metadata') and resource ('for a calendar') and pins the HTTP verb as PUT. It then names the six siblings over the same resource, so an agent can distinguish update from patch/insert/get/delete 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 Guidelines3/5

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

It lists siblings (clear, delete, get, insert, patch, transferOwnership) and notes refusal under --readonly profiles, which hints at mutation context. But it never states when to choose update (full PUT replace) over patch (partial update) — the most common decision an agent faces here.

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

Deploy Server