Google Workspace MCP Server - Control Gmail, Calendar, Docs, Sheets, Slides, Chat, Forms & Drive

Create Drive File

create_drive_file

Create a new file in Google Drive with text, base64 bytes, or a URL source. Store it in any folder or shared drive without format conversion.

Instructions

Creates a new file in Google Drive, supporting creation within shared drives. Accepts direct text content, inline base64 bytes, or a fileUrl to fetch content from. This stores the supplied bytes without converting them to Google Docs, Sheets, or Slides. Use the matching import_to_google_* tool for Google-native conversion.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`content`	No	If provided, the content to write to the file.
`fileUrl`	No	If provided, fetches the file content from this URL. Supports file://, http://, and https:// protocols.
`file_name`	Yes	The name for the new file.
`folder_id`	No	The ID of the parent folder. Defaults to 'root'. For shared drives, this must be a folder ID within the shared drive.	root
`mime_type`	No	The MIME type of the file. Defaults to 'text/plain'; required with return_upload_url.
`base64_sha256`	No	Expected SHA-256 of decoded base64_content. Recommended for binary payload integrity checks.
`base64_content`	No	Standard base64-encoded file bytes.
`content_mime_type`	No	MIME type for base64_content uploads.
`user_google_email`	Yes	The user's Google email address. Required.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedv1.28.0Sep 24, 2026

removedInput schema / properties / base64_content / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / base64_content / type
```
Added value: +"string"
```

removedInput schema / properties / base64_sha256 / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / base64_sha256 / type
```
Added value: +"string"
```

removedInput schema / properties / content / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / content / type
```
Added value: +"string"
```

removedInput schema / properties / content_mime_type / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / content_mime_type / type
```
Added value: +"string"
```

removedInput schema / properties / fileUrl / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / fileUrl / type
```
Added value: +"string"
```
changedInput schema / properties / mime_type / default
```
Previous value: -"text/plain"New value: +null
```

changedInput schema / properties / mime_type / description

Previous value: -"The MIME type of the file. Defaults to 'text/plain'."New value: +"The MIME type of the file. Defaults to 'text/plain'; required with return_upload_url."

Changed1 schema field changedv1.25.2Aug 30, 2026

addedInput schema / properties / base64_sha256

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Expected SHA-256 of decoded base64_content. Recommended for binary payload integrity checks."
+}

Addedv1.0.1Jul 31, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already establish readOnlyHint=false and destructiveHint=false Fibonacci, so the write-but-not-destructive safety profile is covered. The description adds meaningful behavioral context: it stores bytes without converting to Google native formats, and it supports shared drives. It does not dive into auth or side effects, but given annotation coverage, this is sufficient.

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?

Three sentences with no fluff: purpose first, then input modes, then the conversion caveat and alternative. Every sentence carries distinct information and the structure front-loads the core definition.

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 tool with 9 parameters and an output schema, the description covers the main use cases, the shared-drive capability, and the critical non-conversion behavior. It does not mention potential error conditions or parameter interactions, but the 100% schema coverage and output schema reduce the need. It is complete enough for an agent to invoke correctly.

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 baseline is 3. The description's mention of 'direct text content, inline base64 bytes, or a fileUrl' maps to existing schema parameters (content, base64_content, fileUrl) without adding new semantics like mutual exclusivity or precedence. It adds marginal grouping value but does not compensate beyond the schema.

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 ('Creates') and resource ('a new file in Google Drive'), and explicitly scopes to shared drives. It distinguishes itself from the import_to_google_* siblings by clarifying it stores bytes without converting, making the tool's role unambiguous.

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

Usage Guidelines5/5

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

Explicitly tells the agent when not to use this tool: 'Use the matching import_to_google_* tool for Google-native conversion.' It also lists the three supported content input modes (text, base64, fileUrl), giving clear contextual guidance for choosing this tool over siblings.

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

Deploy Server