Skip to main content
Glama
debanjanbasu

grr

by debanjanbasu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

drive.files.delete

Permanently deletes a Google Drive file owned by the user without trashing it; the action is irreversible and shared-drive parents require organizer access.

Instructions

Permanently deletes a file owned by the user without moving it to the trash. For more information, see Trash or delete files and folders. If the file belongs to a shared drive, the user must be an organizer on the parent folder. If the target is a folder, all descendants owned by the user are also deleted [HTTP DELETE] — removes the resource; irreversible unless the API documents a trash/undo flow; refused under --readonly safety profiles. Returns the post-delete resource state (or empty) 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, download, emptyTrash, export, generateCseToken, generateIds, get, list, listLabels, modifyLabels, update, watch.

Input Schema

NameRequiredDescriptionDefault
queryNoExtra KEY=VALUE query pairs for endpoints whose parameters Discovery does not describe.
fileIdYes[URL path segment] The ID of the file.
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.
supportsAllDrivesNo[query parameter] Whether the requesting application supports both My Drives and shared drives.false
supportsTeamDrivesNo[query parameter] Deprecated: Use `supportsAllDrives` instead.false
enforceSingleParentNo[query parameter] Deprecated: If an item isn't in a shared drive and its last parent is deleted but the item itself isn't, the item will be placed under its owner's root.false

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • addedInput schema / properties / enforceSingleParent / default
      Added value: +"false"
    • changedInput schema / properties / enforceSingleParent / description
      Previous value: -"Deprecated: If an item isn't in a shared drive and its last parent is deleted but the item itself isn't, the item will be placed under its owner's root."New value: +"[query parameter] Deprecated: If an item isn't in a shared drive and its last parent is deleted but the item itself isn't, the item will be placed under its owner's root."
    • 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 / 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."
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: permanent/irreversible, no trash fallback, cascade deletion of descendants when the target is a folder, shared-drive permission requirement, and the post-delete return value. It also flags refusal under read-only safety profiles.

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 permission and irreversibility facts are front-loaded and earn their place, but the 'request bodies are built from typed parameters… body_file' boilerplate is irrelevant to a bodyless DELETE and the long sibling enumeration adds bulk without routing guidance.

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 an 8-parameter destructive tool with no annotations and no output schema, the description covers side effects, permissions, irreversibility, and return shape. Missing only an explicit steer to the recoverable alternative, which is the main thing an agent deciding 'delete or trash?' would want.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema baseline is 3; the description adds value by explaining precedence between typed flags, the `params` map, and `body_file`, and by tying the organizer requirement to shared-drive context. It still doesn't clarify when supportsAllDrives vs the deprecated supportsTeamDrives should be set.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource with a crucial scope qualifier: 'Permanently deletes a file owned by the user without moving it to the trash.' This immediately separates it from trash-based flows like gmail.users.messages.trash or a soft-delete via update.

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

Usage Guidelines4/5

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

Gives clear preconditions (file must be owned by the user; must be an `organizer` on the parent folder for shared-drive files) and signals permanence so the agent knows this is not the recoverable path. It does not explicitly name an alternative tool (e.g., emptyTrash or update-to-trash), so it falls short of a 5.

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