grr

Overview Schema Source Related Servers Discussions Admin

drive.files.watch

Subscribes to change notifications for a Google Drive file by creating a push channel, returning the API response as JSON; rejected in read-only safety profiles.

Instructions

Subscribes to changes to a file. 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: copy, create, delete, download, emptyTrash, export, generateCseToken, generateIds, get, list, listLabels, modifyLabels, update.

Input Schema

Name	Required	Description	Default
`query`	No	Extra KEY=VALUE query pairs for endpoints whose parameters Discovery does not describe.
`fileId`	Yes	[URL path segment] The ID of the file.
`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.
`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.
`acknowledgeAbuse`	No	[query parameter] Whether the user is acknowledging the risk of downloading known malware or other abusive files. This is only applicable when the `alt` parameter is set to `medi	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
`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"
+}

Changed10 schema fields changedOct 26, 2026

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

changedInput schema / properties / acknowledgeAbuse / description

Previous value: -"Whether the user is acknowledging the risk of downloading known malware or other abusive files. This is only applicable when the `alt` parameter is set to `medi"New value: +"[query parameter] Whether the user is acknowledging the risk of downloading known malware or other abusive files. This is only applicable when the `alt` parameter is set to `medi"

changedInput schema / properties / fileId / description

Previous value: -"The ID of the file."New value: +"[URL path segment] The ID of the file."

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 / 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."

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 load well: it discloses that this is a mutating HTTP POST that 'creates or triggers a change', that it is blocked under readonly safety profiles, and that it returns the API response resource as JSON. Missing lifecycle context — that the channel must later be stopped or that expirations need renewal — keeps it below 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.

Conciseness4/5

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

The core purpose and safety constraint are front-loaded in the first two clauses, and the body-passing note is compact. The 'and 2 more fields' phrasing is vague and the trailing sibling enumeration is low-value filler.

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 nested-body tool with 11 parameters, the description covers what matters: the operation is a subscription, it is write-like and blocked in readonly mode, the body is a Channel object, and how to pass it. An output schema exists so return-value detail is not needed; only channel teardown/expiration guidance is absent.

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 description coverage is 100%, so the baseline is 3. The description does add how the body may be supplied ('via params or whole via body_file') and enumerates Channel fields, but the schema already exposes the same request_body shape and body_file semantics.

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 first sentence gives a specific verb and resource: 'Subscribes to changes to a file.' The follow-up adds that it is an HTTP POST that creates/triggers a change, which sharpens the operation. The sibling list at the end is a raw dump rather than a functional contrast, so the closest neighbor (drive.changes.watch, watching the whole drive) is never disambiguated.

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?

Implicit guidance comes from 'Subscribes to changes to a file' plus the safety note that it is refused under --readonly profiles. But there is no explicit when-to-use versus drive.changes.watch or calendar.events.watch, and the trailing sibling list adds names without routing criteria.

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

Deploy Server