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

Manage Doc Tab

manage_doc_tab

Destructive

Create, rename, delete, or populate Google Docs tabs from Markdown to organize document structure and content.

Instructions

Manage document tabs: create, rename, delete, or populate from Markdown.

Input Schema

TableJSON Schema

Name	Required	Description
`index`	No	Position index for new tab, 0-based among siblings (required for create)
`title`	No	Tab title (required for create; used by rename)
`action`	Yes	Action to perform - "create", "rename", "delete", or "populate_from_markdown"
`tab_id`	No	Tab ID (required for rename, delete, populate_from_markdown; use inspect_doc_structure to find IDs)
`document_id`	Yes	ID of the document
`markdown_text`	No	Markdown source to render (populate_from_markdown only)
`parent_tab_id`	No	Optional parent tab ID to nest under (create only)
`replace_existing`	No	Clear tab body before inserting markdown (default True)
`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.

Changed10 schema fields changedv1.28.0Sep 24, 2026

removedInput schema / properties / index / anyOf

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

addedInput schema / properties / index / type
```
Added value: +"integer"
```

removedInput schema / properties / markdown_text / anyOf

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

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

removedInput schema / properties / parent_tab_id / anyOf

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

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

removedInput schema / properties / tab_id / anyOf

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

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

removedInput schema / properties / title / anyOf

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

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

Addedv1.0.1Jul 31, 2026

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description lists destructive actions (delete) and creation, consistent with annotations, but adds no further behavioral context such as consequences of populate_from_markdown on existing content or auth requirements.

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?

Single sentence with no fluff, listing actions in a readable list. It is concise but borders on being a mere restatement of the title and action enum.

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

Completeness2/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 4 distinct actions, the description is too sparse. It does not explain when each action applies, how actions relate to required parameters, or how to obtain tab_id (though the schema hints at inspect_doc_structure). It relies entirely on the schema.

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 does not add parameter-level information beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (document tabs) and enumerates four operations (create, rename, delete, populate from Markdown). It does not explicitly name a sibling tool, but the word 'document' makes it distinguishable from manage_sheet_tab.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like manage_sheet_tab or inspect_doc_structure. It does not mention prerequisites, exclusions, or scenarios for each action.

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

Deploy Server