Skip to main content
Glama
debanjanbasu

grr

by debanjanbasu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

drive.files.generateIds

Generate file IDs for Google Drive create or copy requests, letting you preassign identifiers before uploading or duplicating files.

Instructions

Generates a set of file IDs which can be provided in create or copy requests. For more information, see Create and manage 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, generateCseToken, get, list, listLabels, modifyLabels, update, watch.

Input Schema

NameRequiredDescriptionDefault
typeNo[query parameter] The type of items which the IDs can be used for. Supported values are `files` and `shortcuts`. Note that `shortcuts` are only supported in the `drive` `space`. files
countNo[query parameter] The number of IDs to return.10
queryNoExtra KEY=VALUE query pairs for endpoints whose parameters Discovery does not describe.
spaceNo[query parameter] The space in which the IDs can be used to create files. Supported values are `drive` and `appDataFolder`. (Default: `drive`.) For more information, see [File ordrive
paramsNoParameter map merged into the request; typed parameters win.
dry_runNoReturn the request that would be sent, without sending it.
body_fileNoRead the request body from this file ('-' for stdin) instead of building one from the parameters.

Output Schema

NameRequiredDescriptionDefault
idsNo
kindNo
spaceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changed
    • addedInput schema / properties / count / default
      Added value: +"10"
    • changedInput schema / properties / count / description
      Previous value: -"The number of IDs to return."New value: +"[query parameter] The number of IDs to return."
    • addedInput schema / properties / count / format
      Added value: +"int32"
    • addedInput schema / properties / count / maximum
      Added value: +1000
    • addedInput schema / properties / count / minimum
      Added value: +1
    • addedInput schema / properties / space / default
      Added value: +"drive"
    • changedInput schema / properties / space / description
      Previous value: -"The space in which the IDs can be used to create files. Supported values are `drive` and `appDataFolder`. (Default: `drive`.) For more information, see [File or"New value: +"[query parameter] The space in which the IDs can be used to create files. Supported values are `drive` and `appDataFolder`. (Default: `drive`.) For more information, see [File or"
    • addedInput schema / properties / type / default
      Added value: +"files"
    • changedInput schema / properties / type / description
      Previous value: -"The type of items which the IDs can be used for. Supported values are `files` and `shortcuts`. Note that `shortcuts` are only supported in the `drive` `space`. "New value: +"[query parameter] The type of items which the IDs can be used for. Supported values are `files` and `shortcuts`. Note that `shortcuts` are only supported in the `drive` `space`. "
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "ids": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "kind": {
+      "type": "string"
+    },
+    "space": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  2. First observed

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses [HTTP GET] (a useful read-only signal) but then adds generic boilerplate about request bodies, typed flags vs. `params`, and `body_file` that is largely inapplicable to a query-only GET endpoint, and it omits the genuinely important behavior — whether returned IDs are reserved/guaranteed unique or must be used promptly.

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

Conciseness5/5

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

Wait — the structure is front-loaded correctly but the second half is boilerplate about body_file and a long sibling name dump, so it is not waste-free. Corrected to 2: the opening sentence earns its place; the request-body boilerplate does not apply to a GET request and the sibling enumeration adds little.

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

Completeness3/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 is covered. But for a 7-parameter endpoint with nesting (`params`), the description omits the semantics that matter (ID uniqueness/lifetime, relationship to create/copy) while padding with inapplicable body-construction text.

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%, with `type`, `count`, `space`, and `query` all documented in the schema, so the baseline of 3 applies. The description adds no per-parameter meaning (e.g. practical limits on `count` or when `type=shortcuts` is legal) beyond what the schema already states.

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 — "Generates a set of file IDs which can be provided in create or copy requests" — which is unambiguous and matches the tool name. However, the sibling section only lists sibling names (copy, create, delete, ...) without saying how generateIds differs from just calling create, so differentiation is enumerated rather than explained.

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?

"can be provided in create or copy requests" implies the intended workflow (pre-fetch an ID when you need it before creating), but the description never states the condition explicitly, e.g. "use when you need the ID before the file exists." The sibling list names alternatives without offering any selection criteria, leaving the agent to infer placement in the workflow.

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

Deploy Server

Other Tools