grr

Overview Schema Source Related Servers Discussions Admin

calendar.acl.watch

Watch calendar ACL resources for changes by creating a notification channel via HTTP POST; returns the API response as JSON and is refused under readonly safety profiles.

Instructions

Watch for changes to ACL resources [HTTP POST] — creates or triggers a change; refused under --readonly safety profiles. Returns the API's response resource as JSON — request body is a JSON Channel object accepting address, expiration, id, kind, params, payload, resourceId, resourceUri and 2 more fields; pass it via params or whole via body_file Siblings over the same resource: delete, get, insert, list, patch, update.

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 Channel object.
`pageToken`	No	[query parameter] Token specifying which result page to return. Optional.
`syncToken`	No	[query parameter] Token obtained from the nextSyncToken field returned on the last page of results from the previous list request. It makes the result of this list request contai
`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
`maxResults`	No	[query parameter] Maximum number of entries returned on one result page. By default the value is 100 entries. The page size can never be larger than 250 entries. Optional.
`showDeleted`	No	[query parameter] Whether to include deleted ACLs in the result. Deleted ACLs are represented by role equal to "none". Deleted ACLs will always be included if syncToken is provid
`request_body`	No	Request body of type Channel: pass it via `params` (merged into the built body) or whole via `body_file`.

Output Schema

Name	Required	Description	Default
`id`	No
`kind`	No
`type`	No
`token`	No
`params`	No
`address`	No
`payload`	No
`expiration`	No
`resourceId`	No
`resourceUri`	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 Channel object."

addedInput schema / properties / request_body

Added value: +{
+  "description": "Request body of type Channel: pass it via `params` (merged into the built body) or whole via `body_file`.",
+  "properties": {
+    "address": {
+      "type": "string"
+    },
+    "expiration": {
+      "type": "string"
+    },
+    "id": {
+      "type": "string"
+    },
+    "kind": {
+      "type": "string"
+    },
+    "params": {
+      "type": "object"
+    },
+    "payload": {
+      "type": "boolean"
+    },
+    "resourceId": {
+      "type": "string"
+    },
+    "resourceUri": {
+      "type": "string"
+    },
+    "token": {
+      "type": "string"
+    },
+    "type": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changed8 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"

changedInput schema / properties / maxResults / description

Previous value: -"Maximum number of entries returned on one result page. By default the value is 100 entries. The page size can never be larger than 250 entries. Optional."New value: +"[query parameter] Maximum number of entries returned on one result page. By default the value is 100 entries. The page size can never be larger than 250 entries. Optional."

addedInput schema / properties / maxResults / format
```
Added value: +"int32"
```
addedInput schema / properties / maxResults / minimum
```
Added value: +1
```

changedInput schema / properties / pageToken / description

Previous value: -"Token specifying which result page to return. Optional."New value: +"[query parameter] Token specifying which result page to return. Optional."

changedInput schema / properties / showDeleted / description

Previous value: -"Whether to include deleted ACLs in the result. Deleted ACLs are represented by role equal to \"none\". Deleted ACLs will always be included if syncToken is provid"New value: +"[query parameter] Whether to include deleted ACLs in the result. Deleted ACLs are represented by role equal to \"none\". Deleted ACLs will always be included if syncToken is provid"

changedInput schema / properties / syncToken / description

Previous value: -"Token obtained from the nextSyncToken field returned on the last page of results from the previous list request. It makes the result of this list request contai"New value: +"[query parameter] Token obtained from the nextSyncToken field returned on the last page of results from the previous list request. It makes the result of this list request contai"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "address": {
+      "type": "string"
+    },
+    "expiration": {
+      "type": "string"
+    },
+    "id": {
+      "type": "string"
+    },
+    "kind": {
+      "type": "string"
+    },
+    "params": {
+      "type": "object"
+    },
+    "payload": {
+      "type": "boolean"
+    },
+    "resourceId": {
+      "type": "string"
+    },
+    "resourceUri": {
+      "type": "string"
+    },
+    "token": {
+      "type": "string"
+    },
+    "type": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedOct 26, 2026

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses that this is a mutating POST, that it is blocked under read-only profiles, and that it returns the API's response resource as JSON. It omits auth requirements and watch-channel lifetime/expiration behavior, keeping it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The verb and safety caveat are front-loaded, which is good, but the rest is a single run-on sentence that repeats the 'pass via params or body_file' instruction already present in the schema and duplicates the trailing sibling list. It is dense rather than wasteful, but could be tightened.

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?

An output schema exists, so return-value explanation is optional, and the description still covers the mutating nature, the read-only refusal, and body construction. For a 10-parameter watch tool it is nearly complete, missing only auth/permission and channel-expiry details.

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 baseline is 3, and the description adds value by enumerating the Channel body fields (address, expiration, id, kind, params, payload, resourceId, resourceUri) and explaining the two delivery paths (params vs body_file). The field list largely mirrors the request_body schema, capping it at 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a concrete verb and resource ('Watch for changes to ACL resources') and clarifies the mechanism is an HTTP POST that creates/triggers a change. It names the sibling operations on the same resource, but only as a bare list rather than routing criteria, so differentiation is partial.

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 provides one real usage condition — 'refused under --readonly safety profiles' — which tells an agent when it will fail. However, it never states when to prefer this over siblings like list or get, leaving alternative selection implied by the trailing enumeration.

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

Deploy Server