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

Create Doc

create_doc

Create a new Google Doc with optional initial content in a specified folder. Provide user email, title, and folder ID to generate the document.

Instructions

Creates a new Google Doc and optionally inserts initial content.

After creation, the document body starts at index 1. A new empty doc has total length 2 (one section break at index 0, one newline at index 1).

To build a rich document after creation, use batch_update_doc with insert_text operations using end_of_segment=true to append content sequentially without calculating indices. Then call inspect_doc_structure to get exact positions before applying formatting in a separate batch call.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`title`	Yes	Title of the new document
`content`	No	Optional initial plain text content to insert
`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
`user_google_email`	Yes	User's Google email address

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.28.0Sep 24, 2026

addedInput schema / properties / folder_id

Added value: +{
+  "default": "root",
+  "description": "The ID of the parent folder. Defaults to 'root'. For shared\ndrives, this must be a folder ID within the shared drive.",
+  "type": "string"
+}

Changed11 schema fields changedv1.0.1Jul 31, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / properties / content / description

Added value: +"Optional initial plain text content to insert"

removedInput schema / properties / content / title
```
Removed value: -"Content"
```

removedInput schema / properties / service

Removed value: -{
-  "title": "service",
-  "type": "string"
-}

addedInput schema / properties / title / description
```
Added value: +"Title of the new document"
```
removedInput schema / properties / title / title
```
Removed value: -"Title"
```
addedInput schema / properties / user_google_email / description
```
Added value: +"User's Google email address"
```
removedInput schema / properties / user_google_email / title
```
Removed value: -"User Google Email"
```

changedInput schema / required

Previous value: -[
-  "service",
-  "user_google_email",
-  "title"
-]New value: +[
+  "user_google_email",
+  "title"
+]

removedInput schema / title
```
Removed value: -"create_docArguments"
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "type": "object",
+  "x-fastmcp-wrap-result": true
+}

First observedv1.0.0Jun 10, 2025

TDQS

A4.3/5.0

Behavior4/5

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

Annotations only indicate readOnlyHint=false, openWorldHint=true, etc., offering little safety context. The description adds valuable behavioral details—document body starts at index 1, empty doc length is 2, and the recommended workflow for building content—which goes beyond annotations and enriches the agent's understanding of the tool's effects without contradicting the annotations.

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?

The description is organized into three clear paragraphs: purpose, structural details, and workflow. It is front-loaded with the core purpose and each sentence serves a function. While not extremely concise, the structure is logical and free of fluff, earning a 4.

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?

Given the output schema exists and the description covers creation behavior and explicitly links to sibling tools for subsequent steps, it is fairly complete. It doesn't mention error handling or permissions, but those are not necessarily required for a creation tool when output schema is present. The guidance on using batch_update_doc and inspect_doc_structure fills practical gaps, making it adequate.

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 all parameters (title, content, folder_id, user_google_email) are already documented. The description does add that content is 'optional initial plain text' and that folder_id defaults to 'root', but these are also present in the schema. It adds no new meaning beyond the schema, so baseline 3 is appropriate.

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 states a specific verb ('Creates'), a resource ('a new Google Doc'), and an optional capability ('inserts initial content'). It clearly distinguishes from siblings by explicitly directing to use batch_update_doc for rich content and inspect_doc_structure for positions, 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?

The description explicitly provides when-to-use guidance: 'To build a rich document after creation, use batch_update_doc...' and 'Then call inspect_doc_structure...'. This tells the agent exactly when to use this tool versus alternatives and what steps follow, eliminating inference.

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

Deploy Server