grr

Overview Schema Source Related Servers Discussions Admin

drive.changes.watch

Subscribe to Google Drive change notifications by creating a push channel, so your app can receive updates when files or shared drive items change.

Instructions

Subscribes to changes for a user. For more information, see Notifications for resource changes [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: getStartPageToken, list.

Input Schema

Name	Required	Description	Default
`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.
`spaces`	No	[query parameter] A comma-separated list of spaces to query within the corpora. Supported values are 'drive' and 'appDataFolder'.	drive
`driveId`	No	[query parameter] The shared drive from which changes will be returned. If specified the change IDs will be reflective of the shared drive; use the combined drive ID and change I
`dry_run`	No	Return the request that would be sent, without sending it.
`pageSize`	No	[query parameter] The maximum number of changes to return. The service may return fewer than this value. If unspecified, at most 100 changes will be returned. The maximum value i	100
`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`	Yes	[query parameter] The token for continuing a previous list request on the next page. This should be set to the value of 'nextPageToken' from the previous response or to the respo
`teamDriveId`	No	[query parameter] Deprecated: Use `driveId` instead.
`request_body`	No	Request body of type Channel: pass it via `params` (merged into the built body) or whole via `body_file`.
`includeLabels`	No	[query parameter] A comma-separated list of IDs of labels to include in the `labelInfo` part of the response.
`includeRemoved`	No	[query parameter] Whether to include changes indicating that items have been removed from the list of changes, for example by deletion or loss of access.	true
`restrictToMyDrive`	No	[query parameter] Whether to restrict the results to changes inside the My Drive hierarchy. This omits changes to files such as those in the Application Data folder or shared fil	false
`supportsAllDrives`	No	[query parameter] Whether the requesting application supports both My Drives and shared drives.	false
`supportsTeamDrives`	No	[query parameter] Deprecated: Use `supportsAllDrives` instead.	false
`includeCorpusRemovals`	No	[query parameter] Whether changes should include the file resource if the file is still accessible by the user at the time of the request, even when a file was removed from the l	false
`includeTeamDriveItems`	No	[query parameter] Deprecated: Use `includeItemsFromAllDrives` instead.	false
`includeItemsFromAllDrives`	No	[query parameter] Whether both My Drive and shared drive items should be included in results.	false
`includePermissionsForView`	No	[query parameter] Specifies which additional view's permissions to include in the response. Only 'published' is supported.

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"
+}

Changed27 schema fields changedOct 26, 2026

changedInput schema / properties / driveId / description

Previous value: -"The shared drive from which changes will be returned. If specified the change IDs will be reflective of the shared drive; use the combined drive ID and change I"New value: +"[query parameter] The shared drive from which changes will be returned. If specified the change IDs will be reflective of the shared drive; use the combined drive ID and change I"

addedInput schema / properties / includeCorpusRemovals / default
```
Added value: +"false"
```

changedInput schema / properties / includeCorpusRemovals / description

Previous value: -"Whether changes should include the file resource if the file is still accessible by the user at the time of the request, even when a file was removed from the l"New value: +"[query parameter] Whether changes should include the file resource if the file is still accessible by the user at the time of the request, even when a file was removed from the l"

addedInput schema / properties / includeItemsFromAllDrives / default
```
Added value: +"false"
```

changedInput schema / properties / includeItemsFromAllDrives / description

Previous value: -"Whether both My Drive and shared drive items should be included in results."New value: +"[query parameter] Whether both My Drive and shared drive items should be included in results."

changedInput schema / properties / includeLabels / description

Previous value: -"A comma-separated list of IDs of labels to include in the `labelInfo` part of the response."New value: +"[query parameter] A comma-separated list of IDs of labels to include in the `labelInfo` part of the response."

changedInput schema / properties / includePermissionsForView / description

Previous value: -"Specifies which additional view's permissions to include in the response. Only 'published' is supported."New value: +"[query parameter] Specifies which additional view's permissions to include in the response. Only 'published' is supported."

addedInput schema / properties / includeRemoved / default
```
Added value: +"true"
```

changedInput schema / properties / includeRemoved / description

Previous value: -"Whether to include changes indicating that items have been removed from the list of changes, for example by deletion or loss of access."New value: +"[query parameter] Whether to include changes indicating that items have been removed from the list of changes, for example by deletion or loss of access."

addedInput schema / properties / includeTeamDriveItems / default
```
Added value: +"false"
```

changedInput schema / properties / includeTeamDriveItems / description

Previous value: -"Deprecated: Use `includeItemsFromAllDrives` instead."New value: +"[query parameter] Deprecated: Use `includeItemsFromAllDrives` instead."

addedInput schema / properties / pageSize / default
```
Added value: +"100"
```

changedInput schema / properties / pageSize / description

Previous value: -"The maximum number of changes to return. The service may return fewer than this value. If unspecified, at most 100 changes will be returned. The maximum value i"New value: +"[query parameter] The maximum number of changes to return. The service may return fewer than this value. If unspecified, at most 100 changes will be returned. The maximum value i"

addedInput schema / properties / pageSize / format
```
Added value: +"int32"
```
addedInput schema / properties / pageSize / maximum
```
Added value: +1000
```
addedInput schema / properties / pageSize / minimum
```
Added value: +1
```

changedInput schema / properties / pageToken / description

Previous value: -"The token for continuing a previous list request on the next page. This should be set to the value of 'nextPageToken' from the previous response or to the respo"New value: +"[query parameter] The token for continuing a previous list request on the next page. This should be set to the value of 'nextPageToken' from the previous response or to the respo"

addedInput schema / properties / restrictToMyDrive / default
```
Added value: +"false"
```

changedInput schema / properties / restrictToMyDrive / description

Previous value: -"Whether to restrict the results to changes inside the My Drive hierarchy. This omits changes to files such as those in the Application Data folder or shared fil"New value: +"[query parameter] Whether to restrict the results to changes inside the My Drive hierarchy. This omits changes to files such as those in the Application Data folder or shared fil"

addedInput schema / properties / spaces / default
```
Added value: +"drive"
```

changedInput schema / properties / spaces / description

Previous value: -"A comma-separated list of spaces to query within the corpora. Supported values are 'drive' and 'appDataFolder'."New value: +"[query parameter] A comma-separated list of spaces to query within the corpora. Supported values are 'drive' and 'appDataFolder'."

addedInput schema / properties / supportsAllDrives / default
```
Added value: +"false"
```

changedInput schema / properties / supportsAllDrives / description

Previous value: -"Whether the requesting application supports both My Drives and shared drives."New value: +"[query parameter] Whether the requesting application supports both My Drives and shared drives."

addedInput schema / properties / supportsTeamDrives / default
```
Added value: +"false"
```

changedInput schema / properties / supportsTeamDrives / description

Previous value: -"Deprecated: Use `supportsAllDrives` instead."New value: +"[query parameter] Deprecated: Use `supportsAllDrives` instead."

changedInput schema / properties / teamDriveId / description

Previous value: -"Deprecated: Use `driveId` instead."New value: +"[query parameter] Deprecated: Use `driveId` instead."

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.8/5.0

Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses the HTTP POST method, that it creates/triggers a change, and that it is refused under --readonly safety profiles — a non-obvious operational constraint. It also documents the request-body mechanism and the JSON return, though it does not mention channel renewal/expiration lifecycle behavior.

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-loaded with purpose, then the mutating/safety caveat, then body mechanics, then sibling routing. Dense but every clause carries information; only minor redundancy between the Channel field list and the schema's request_body description.

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 complex 19-param watch tool with an output schema and no annotations, the description covers the safety profile, the POST/mutation nature, body construction, and sibling routing — enough to call it correctly. The remaining gap is the pageToken provenance (getStartPageToken) which is central to a watch workflow but only hinted at via the sibling list.

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 already 100%, so the baseline is 3; the description adds meaning by explaining the Channel body fields (address, expiration, id, kind, params, payload, resourceId, resourceUri, +2) and the two delivery paths — merged via `params` or whole via `body_file`. That dual-delivery nuance is genuinely useful for a 19-param tool with a nested body, even though some of it echoes the schema text.

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?

"Subscribes to changes for a user" states a specific verb (subscribes) and resource (changes), and the later note names the siblings over the same resource (getStartPageToken, list), so an agent can distinguish this from a plain change listing. It stops short of 5 because the description never says the mechanism explicitly (a push-notification channel/webhook), leaving that to be inferred from the linked doc and the Channel body.

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 names the two sibling tools that operate on the same resource but does not say when to pick this one over them beyond the implicit "watch vs list" distinction. Critically, the required pageToken is presumably obtained from getStartPageToken, yet the description does not state that prerequisite, leaving setup order to inference.

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

Deploy Server