grr

Overview Schema Source Related Servers Discussions Admin

drive.revisions.list

List a file's revisions by file ID and page through results to inspect change history. Use it to retrieve revision metadata for Google Drive files.

Instructions

Lists a file's revisions. For more information, see Manage file revisions. Important: The list of revisions returned by this method might be incomplete for files with a large revision history, including frequently edited Google Docs, Sheets, and Slides. Older revisions might be omitted from the response, meaning the first revision returned may not be the oldest existing revision. The revision history visible in the Workspace editor user interface might be more complete than the list returned by the API [HTTP GET]. Returns the requested resource as JSON — request bodies are built from the typed parameters (typed flags win over the params map), or read whole from body_file Siblings over the same resource: delete, get, 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.
`pageSize`	No	[query parameter] The maximum number of revisions to return. The service may return fewer than this value. If unspecified, at most 200 revisions will be returned. The maximum val	200
`body_file`	No	Read the request body from this file ('-' for stdin) instead of building one from the parameters.
`pageToken`	No	[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.

Output Schema

Name	Required	Description	Default
`kind`	No
`revisions`	No
`nextPageToken`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedOct 26, 2026

changedInput schema / properties / fileId / description

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

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

changedInput schema / properties / pageSize / description

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

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

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "kind": {
+      "type": "string"
+    },
+    "nextPageToken": {
+      "type": "string"
+    },
+    "revisions": {
+      "items": {
+        "properties": {
+          "exportLinks": {
+            "type": "object"
+          },
+          "id": {
+            "type": "string"
+          },
+          "keepForever": {
+            "type": "boolean"
+          },
+          "kind": {
+            "type": "string"
+          },
+          "lastModifyingUser": {
+            "properties": {
+              "displayName": {
+                "type": "string"
+              },
+              "emailAddress": {
+                "type": "string"
+              },
+              "kind": {
+                "type": "string"
+              },
+              "me": {
+                "type": "boolean"
+              },
+              "permissionId": {
+                "type": "string"
+              },
+              "photoLink": {
+                "type": "string"
+              }
+            },
+            "type": "object"
+          },
+          "md5Checksum": {
+            "type": "string"
+          },
+          "mimeType": {
+            "type": "string"
+          },
+          "modifiedTime": {
+            "type": "string"
+          },
+          "originalFilename": {
+            "type": "string"
+          },
+          "publishAuto": {
+            "type": "boolean"
+          },
+          "published": {
+            "type": "boolean"
+          },
+          "publishedLink": {
+            "type": "string"
+          },
+          "publishedOutsideDomain": {
+            "type": "boolean"
+          },
+          "size": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

First observedOct 26, 2026

TDQS

B3.4/5.0

Behavior3/5

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

No annotations are present, so the description carries the full load. It does add real behavioral value by warning that results can be incomplete for large revision histories and that older revisions may be dropped — non-obvious and important. However, it says nothing about auth/scope requirements, permissions, or ordering of returned revisions, which matters for a read tool with no annotation coverage.

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 valuable caveat about incomplete revision history is front-loaded, which is good. But the trailing boilerplate about JSON responses, typed parameters versus the params map, and body_file is generic transport text that dilutes the tool-specific content.

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 shape needn't be explained, and the key correctness risk (truncated revision history) is disclosed. Pagination is covered by the schema. Missing only auth/permission expectations, which is a minor gap for a read operation.

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 schema already documents fileId, pageSize, pageToken, params, query, dry_run, and body_file. The description's only parameter-relevant note (typed flags win over the params map) is generic plumbing rather than added semantic meaning, so baseline 3 applies.

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?

States a specific verb and resource ("Lists a file's revisions") and explicitly frames the sibling set ("delete, get, update"), so the agent can separate it from the other revision operations. It stops short of a crisp differentiator sentence (e.g. "use get to fetch a single revision"), but the intent is unambiguous.

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?

Usage is only implied by the sibling list and by the caveat that the API history may be less complete than the Workspace editor UI. There is no explicit "use this when..." / "do not use when..." guidance nor a pointer to which sibling to pick for a single revision or a restore.

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

Deploy Server