workspace-mcp

Update Drive File

update_drive_file

Destructive

Update a Google Drive file's metadata, properties, or content in one call. Replace content by text, file path, or URL while preserving file ID and sharing.

Instructions

Updates metadata, properties, and/or content of a Google Drive file.

Providing one of content, file_path, or file_url replaces the file's content in place. The source is uploaded with its source MIME type so the Drive API applies the same format conversion as import_to_google_doc (markdown headings, tables, bold, etc.) while preserving the existing file ID, sharing, comments, and links. Metadata and content can be updated in a single call.

Input Schema

TableJSON Schema

Name	Required	Description
`user_google_email`	Yes	The user's Google email address. Required.
`file_id`	Yes	The ID of the file to update. Required.
`name`	No	New name for the file.
`description`	No	New description for the file.
`mime_type`	No	New MIME type (note: changing type may require content upload).
`add_parents`	No	Comma-separated folder IDs to add as parents.
`remove_parents`	No	Comma-separated folder IDs to remove from parents.
`starred`	No	Whether to star/unstar the file.
`trashed`	No	Whether to move file to/from trash.
`writers_can_share`	No	Whether editors can share the file.
`copy_requires_writer_permission`	No	Whether copying requires writer permission.
`properties`	No	Custom key-value properties for the file.
`content`	No	New text content for text-based formats (markdown, TXT, HTML).
`file_path`	No	Local file path for binary formats (DOCX, ODT). Supports file:// URLs.
`file_url`	No	Remote http(s) URL to fetch new content from.
`source_format`	No	Source format hint for conversion (md, markdown, docx, txt, html, rtf, odt). Auto-detected when omitted. Provide at most one of content/file_path/file_url.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.21.3Jun 18, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Beyond the annotations (destructiveHint=true), the description discloses that providing content, file_path, or file_url replaces content in place while preserving the existing file ID, sharing, comments, and links. It also explains the MIME type conversion behavior, adding material context about side effects.

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?

Two focused paragraphs with the main action stated first, followed by essential behavior details. No filler or redundancy.

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 a 16-parameter tool, the description covers the primary update semantics, content source options, conversion behavior, and preservation guarantees. It references the related tool for format specifics and relies on the output schema for return values, making it well-rounded for agent comprehension.

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?

Input schema covers all 16 parameters with descriptions (100% coverage), and the source_format already states 'Provide at most one of content/file_path/file_url.' The description's mention of the same constraint and 'Metadata and content can be updated in a single call' adds minor usage nuance but does not significantly expand parameter semantics.

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?

The description opens with a specific verb and resource: 'Updates metadata, properties, and/or content of a Google Drive file.' It further distinguishes from create/import by noting in-place replacement and preservation of file ID, sharing, comments, and links.

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?

Context is clear that this tool is for modifying an existing drive file, with mention of content replacement options. It references import_to_google_doc for format conversion but does not explicitly name alternatives like create_drive_file or state when not to use this tool, so it stops short of full exclusion guidance.

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

Deploy Server