grr

Overview Schema Source Related Servers Discussions Admin

drive.files.download

Downloads a Google Drive file by ID, letting you retrieve file content or export Workspace documents with an optional MIME type and revision.

Instructions

Downloads the content of a file. For more information, see Download and export files. Operations are valid for 24 hours from the time of creation [HTTP POST] — creates or triggers a change; refused under --readonly safety profiles. Returns the API's response 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: copy, create, delete, emptyTrash, export, generateCseToken, generateIds, get, list, listLabels, modifyLabels, update, watch.

Input Schema

Name	Required	Description
`query`	No	Extra KEY=VALUE query pairs for endpoints whose parameters Discovery does not describe.
`fileId`	Yes	[URL path segment] Required. The ID of the file to download.
`params`	No	Parameter map merged into the request; typed parameters win.
`dry_run`	No	Return the request that would be sent, without sending it.
`mimeType`	No	[query parameter] Optional. The MIME type the file should be downloaded as. This field can only be set when downloading Google Workspace documents. For a list of supported MIME t
`body_file`	No	Read the request body from this file ('-' for stdin) instead of building one from the parameters.
`revisionId`	No	[query parameter] Optional. The revision ID of the file to download. This field can only be set when downloading blob files, Google Docs, and Google Sheets. Returns `INVALID_ARGU

Output Schema

Name	Required	Description	Default
`done`	No
`name`	No
`error`	No
`metadata`	No
`response`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 26, 2026

changedInput schema / properties / fileId / description

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

changedInput schema / properties / mimeType / description

Previous value: -"Optional. The MIME type the file should be downloaded as. This field can only be set when downloading Google Workspace documents. For a list of supported MIME t"New value: +"[query parameter] Optional. The MIME type the file should be downloaded as. This field can only be set when downloading Google Workspace documents. For a list of supported MIME t"

changedInput schema / properties / revisionId / description

Previous value: -"Optional. The revision ID of the file to download. This field can only be set when downloading blob files, Google Docs, and Google Sheets. Returns `INVALID_ARGU"New value: +"[query parameter] Optional. The revision ID of the file to download. This field can only be set when downloading blob files, Google Docs, and Google Sheets. Returns `INVALID_ARGU"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "done": {
+      "type": "boolean"
+    },
+    "error": {
+      "properties": {
+        "code": {
+          "type": "integer"
+        },
+        "details": {
+          "items": {
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "message": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "metadata": {
+      "type": "object"
+    },
+    "name": {
+      "type": "string"
+    },
+    "response": {
+      "type": "object"
+    }
+  },
+  "type": "object"
+}

First observedOct 26, 2026

TDQS

C2.9/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 burden. It does disclose some behavior (24-hour operation validity, refusal under read-only profiles, request-body construction), but the claim '[HTTP POST] — creates or triggers a change' is internally inconsistent with a content-download operation and could mislead an agent about side effects and safety.

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

Conciseness2/5

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

The first sentence is well front-loaded, but it is followed by boilerplate about request bodies and body_file that has no bearing on a download, plus a long flat sibling list. Several sentences do not earn their place.

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

Completeness2/5

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

With 7 parameters, a nested params map, an output schema, and no annotations, the description should explain the media/binary nature of the response and the Workspace-document export path. Instead it spends its budget on generic wrapper mechanics and a contradictory POST/mutation note.

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 parameters are already documented. The description only adds generic request-plumbing semantics (typed parameters overriding the params map, body_file), which is irrelevant for a download call and adds nothing about mimeType or revisionId.

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 opening sentence gives a clear verb and resource: 'Downloads the content of a file.' However, it never distinguishes this from the closely related siblings it lists, notably export and get, which an agent must choose between for Workspace docs vs. blobs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

It lists sibling operations but gives no guidance on when to pick download over export or get, nor mentions the key precondition that Workspace-native documents must go through export with a mimeType. The only usage-adjacent statement is a generic wrapper note about read-only safety profiles.

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

Deploy Server