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

Create Doc

create_doc

Creates a new Google Doc with a title and optional plain-text content, and lets you choose a parent folder for organized storage.

Instructions

Creates a new Google Doc and optionally inserts initial content.

content is inserted as plain text (Markdown is not rendered); use import_to_google_doc to create a doc from Markdown.

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

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

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

Behavior5/5

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

Annotations declare the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), and the description adds non-obvious behavioral facts: content lands as plain text with no Markdown rendering, and a fresh doc has body starting at index 1 with total length 2.

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?

Purpose is front-loaded in one sentence, followed by tightly grouped guidance on content semantics, index conventions, and the follow-up tool sequence. No filler sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema is present so return values need no explanation, and the description covers creation semantics, the one surprising input behavior, and the follow-up path for rich documents — everything an agent needs to call this correctly and continue afterward.

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 already documents all four parameters; the description nonetheless adds real meaning for 'content' by stating it is inserted as plain text and that Markdown requires a different tool. folder_id and user_google_email semantics are left to 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?

The first sentence gives a precise verb and resource ('Creates a new Google Doc') plus the optional-content scope, and the second sentence names the sibling it is not (import_to_google_doc) with the condition that selects it.

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?

It explicitly routes away from this tool to import_to_google_doc for Markdown input, and lays out a concrete post-creation workflow: batch_update_doc with end_of_segment=true to append, then inspect_doc_structure before applying formatting.

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

Deploy Server