grr

Overview Schema Source Related Servers Discussions Admin

drive.files.generateCseToken

Generates a CSE token for creating or updating client-side encrypted Drive files, optionally targeting a specific file ID or expected parent.

Instructions

Generates a CSE token which can be used to create or update CSE files [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: copy, create, delete, download, emptyTrash, export, 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`	No	[query parameter] The ID of the file for which the JWT should be generated. If not provided, an id will be generated.
`params`	No	Parameter map merged into the request; typed parameters win.
`parent`	No	[query parameter] The ID of the expected parent of the file. Used when generating a JWT for a new CSE file. If specified, the parent will be fetched, and if the parent is a share
`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.

Output Schema

Name	Required	Description	Default
`jwt`	No
`kind`	No
`fileId`	No
`currentKaclsId`	No
`currentKaclsName`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 26, 2026

changedInput schema / properties / fileId / description

Previous value: -"The ID of the file for which the JWT should be generated. If not provided, an id will be generated."New value: +"[query parameter] The ID of the file for which the JWT should be generated. If not provided, an id will be generated."

changedInput schema / properties / parent / description

Previous value: -"The ID of the expected parent of the file. Used when generating a JWT for a new CSE file. If specified, the parent will be fetched, and if the parent is a share"New value: +"[query parameter] The ID of the expected parent of the file. Used when generating a JWT for a new CSE file. If specified, the parent will be fetched, and if the parent is a share"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "currentKaclsId": {
+      "type": "string"
+    },
+    "currentKaclsName": {
+      "type": "string"
+    },
+    "fileId": {
+      "type": "string"
+    },
+    "jwt": {
+      "type": "string"
+    },
+    "kind": {
+      "type": "string"
+    }
+  },
+  "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 supplied, so the description carries the full burden. It usefully discloses the HTTP method [HTTP GET] and that a JSON resource is returned, but omits CSE-specific behavior such as token lifetime, required encryption setup, and whether an ID is allocated when fileId is absent.

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 first sentence is well front-loaded, but the remaining text is generic boilerplate about building request bodies from typed parameters or body_file — advice that is nonsensical for a [HTTP GET] and is irrelevant here — followed by a long sibling name dump with no routing value.

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 values needn't be explained, and the core purpose plus HTTP method are covered. Given a zero-required-parameter tool with full schema coverage, this is close to complete, though CSE auth/setup context is missing.

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 coverage is 100%, so the schema already documents fileId, parent, query, params, dry_run and body_file. The description's note that 'typed flags win over the params map' restates what the params schema field already says, adding no new parameter meaning.

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?

Opening sentence names a specific verb (generates) and resource (a CSE token) and states its downstream use (creating/updating CSE files). It does not distinguish this tool from birth from the other ~13 drive.files siblings beyond listing their names, so an agent still has to infer when it applies.

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?

Saying the token 'can be used to create or update CSE files' implies the use case, but there is no explicit condition for choosing this over drive.files.create or update, and no prerequisites for CSE (client-side encryption must be configured) are mentioned.

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

Deploy Server