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

Create Drive File

create_drive_file

Creates a new Google Drive file from text, base64 bytes, or a URL, supports shared-drive folders, and returns an upload URL when local file access is disabled.

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. Where local file access is disabled it can instead return an upload URL for the caller to PUT file bytes to. 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

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 http:// and https://; file:// only where local file access is enabled. Where it is disabled, files on the caller's machine go through an upload URL instead (see the upload-URL parameter, if offered).
`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

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv2.2.0Oct 24, 2026

changedInput schema / properties / fileUrl / description

Previous value: -"If provided, fetches the file content from this URL. Supports file://, http://, and https:// protocols."New value: +"If provided, fetches the file content from this URL. Supports http:// and https://; file:// only where local file access is enabled. Where it is disabled, files on the caller's machine go through an upload URL instead (see the upload-URL parameter, if offered)."

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.3/5.0

Behavior4/5

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

Annotations already declare the write profile (readOnlyHint=false, destructiveHint=false, non-idempotent, open world), so the bar is lower. The description still adds substantive behavior the annotations cannot convey: the three accepted content sources, the upload-URL mode used when local file access is disabled, and the important guarantee that bytes are stored verbatim rather than converted.

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

Conciseness4/5

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

Four short sentences, front-loaded with the core action, each carrying distinct information: what it creates, what inputs it takes, the no-local-access fallback, and the conversion boundary. Slightly dense with edge-case detail but nothing is wasted.

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?

With nine parameters, an output schema present, and full schema coverage, the description supplies the parts structured fields cannot: the input-mode choice and the conversion boundary. It omits size limits, default sharing/permission behavior, and explicit mention of the required identity/folder parameters, but those are adequately covered by the schema.

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 baseline is 3, but the description adds selection guidance for the mutually exclusive content parameters by enumerating text content, inline base64, and fileUrl as alternative input modes — something the schema documents individually but never frames as a choice. It does not explain mime_type/base64_sha256 behavior beyond what the schema already says.

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 ('Creates a new file in Google Drive') plus the shared-drive scope, and explicitly demarcates itself from the import_to_google_* siblings by declaring it stores bytes without conversion. An agent can distinguish it from update_drive_file or copy_drive_file without opening any schema.

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 an explicit routing rule: use the matching import_to_google_* tool when Google-native conversion is wanted. It also explains the upload-URL fallback path when local file access is disabled, which is a real when-to-use condition. It does not discuss create-vs-update or folder-creation prerequisites, so it stops short of full when/when-not coverage.

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

Deploy Server