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

Get Doc as Markdown

get_doc_as_markdown

Read-onlyIdempotent

Retrieve a Google Doc as clean Markdown with headings, lists, tables, links, and comment context preserved, so it can be reused in AI, documentation, or version-control workflows.

Instructions

Reads a Google Doc and returns it as clean Markdown with optional comment context.

Unlike get_doc_content which returns plain text, this tool preserves document formatting as Markdown: headings, bold/italic/strikethrough, links, code spans, ordered/unordered lists with nesting, and tables.

When comments are included (the default), each comment's anchor text — the specific text the comment was attached to — is preserved, giving full context for the discussion.

Input Schema

Name	Required	Description	Default
`tab_id`	No	Optional ID of a single tab to read (from inspect_doc_structure). When given, only that tab's content is rendered, without its child tabs and without a tab heading, and comments are listed as document-wide. When omitted, every tab is rendered. Pass "" to read every tab of a URL that carries ?tab=. This filters output only: the whole document is still fetched.
`document_id`	Yes	ID of the Google Doc (or full URL). When a full URL is provided and it contains a ?tab= query parameter, that tab is used automatically unless tab_id is also specified (explicit tab_id takes precedence).
`comment_mode`	No	How to display comments: - "inline": Footnote-style references placed at the anchor text location (default) - "appendix": All comments grouped at the bottom with blockquoted anchor text - "none": No comments included	inline
`include_colors`	No	Follow text that has an explicit RGB foreground color with "[color: #rrggbb]" (default: False). Theme colors are not shown.
`include_comments`	No	Whether to include comments (default: True)
`include_resolved`	No	Whether to include resolved comments (default: False)
`user_google_email`	Yes	User's Google email address
`suggestions_view_mode`	No	How to render suggestions in the returned content: - "DEFAULT_FOR_CURRENT_ACCESS": Default based on user's access level - "SUGGESTIONS_INLINE": Suggested changes appear inline in the document - "PREVIEW_SUGGESTIONS_ACCEPTED": Preview as if all suggestions were accepted - "PREVIEW_WITHOUT_SUGGESTIONS": Preview as if all suggestions were rejected	DEFAULT_FOR_CURRENT_ACCESS

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv2.2.0Oct 24, 2026

changedInput schema / properties / document_id / description

Previous value: -"ID of the Google Doc (or full URL)"New value: +"ID of the Google Doc (or full URL). When a full URL is provided\nand it contains a ?tab= query parameter, that tab is used automatically\nunless tab_id is also specified (explicit tab_id takes precedence)."

addedInput schema / properties / include_colors

Added value: +{
+  "default": false,
+  "description": "Follow text that has an explicit RGB foreground color\nwith \"[color: #rrggbb]\" (default: False). Theme colors are not shown.",
+  "type": "boolean"
+}

changedInput schema / properties / tab_id / description

Previous value: -"Optional ID of a single tab to read (from inspect_doc_structure).\nWhen given, only that tab's content is rendered, without its child tabs\nand without a tab heading. When omitted, every tab is rendered."New value: +"Optional ID of a single tab to read (from inspect_doc_structure).\nWhen given, only that tab's content is rendered, without its child tabs\nand without a tab heading, and comments are listed as document-wide.\nWhen omitted, every tab is rendered. Pass \"\" to read every tab of a\nURL that carries ?tab=. This filters output only: the whole document\nis still fetched."

Changed2 schema fields changedv1.28.0Sep 24, 2026
- removedInput schema / properties / tab_id / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / tab_id / type
```
Added value: +"string"
```

Changed1 schema field changedv1.26.0Sep 6, 2026

addedInput schema / properties / tab_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional ID of a single tab to read (from inspect_doc_structure).\nWhen given, only that tab's content is rendered, without its child tabs\nand without a tab heading. When omitted, every tab is rendered."
+}

Addedv1.0.1Jul 31, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive behavior, so the description needn't restate safety. It adds real value instead: the specific formatting preserved (headings, lists with nesting, tables), the default-on comment inclusion, and that anchor text is retained for context. It stops short of discussing large-document behavior or output size, which would matter for an 8-parameter reader.

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?

Front-loaded with the core action, then the sibling differentiation, then comment behavior — a sensible order with no filler sentences. There is mild redundancy between 'optional comment context' in the first line and the later 'When comments are included (the default)' paragraph, but nothing that costs an agent comprehension.

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 an output schema present, the description needn't explain return values, and annotations cover the safety profile. It adequately covers the three things an agent would otherwise have to guess: formatting fidelity, comment default behavior, and contrast with get_doc_content. Minor gaps around very large docs or tab-scoped reads (left to the schema) keep it from a 5.

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% and each parameter already has a detailed description, so the schema carries the semantic load. The description adds only a light note that comments are included by default, which the schema's include_comments default already conveys. Baseline 3 applies.

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 ('Reads a Google Doc and returns it as clean Markdown') and immediately names the sibling it differs from, get_doc_content, along with the precise difference (plain text vs. preserved formatting). An agent can distinguish it without opening either 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?

Explicitly routes the agent between this tool and get_doc_content based on whether formatting matters, which is the key selection decision. It does not address other plausible siblings such as inspect_doc_structure or get_drive_file_content, so the guidance is clear but not exhaustive.

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

Deploy Server