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

Get Doc Content

get_doc_content

Read-onlyIdempotent

Retrieve text and document content from Google Docs or Drive files by ID. Works with native docs and Office files, preserving index alignment for precise editing or providing readable context with semantic annotations.

Instructions

Retrieves content of a Google Doc or a Drive file (like .docx) identified by document_id.

Native Google Docs: Fetches content via Docs API.
Office files (.docx, etc.) stored in Drive: Downloads via Drive API and extracts text.

By default, native Google Docs text is index-aligned with the document: empty paragraphs are preserved and every non-text element that occupies an index (inline object, page break, footnote reference, ...) is rendered as one U+FFFC placeholder per index. The document body starts at index 1, so an offset n into the text that follows "--- CONTENT ---" is document index n + 1, and that index can be passed straight to format_text or delete_text. Tables and multi-tab documents interleave separators, so alignment holds up to the first table or tab header.

Set preserve_context=True for readable link destinations, internal targets, smart-chip values, table boundaries, headers, footers, footnotes, and object context exposed by the Docs API. This output is plain text, not Markdown, and its offsets must not be used as document editing indices. Comments, revision history, exact visual layout, and chip details hidden by the API are not included. Use get_doc_as_markdown for formatting or comments.

Input Schema

TableJSON 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 returned with no tab separator, so the default output stays index-aligned with that tab. When omitted, every tab is returned with "--- TAB: ... ---" markers.
`document_id`	Yes	ID of the Google Doc (or full URL)
`preserve_context`	No	Include readable semantic annotations for native Docs. Defaults to False to retain index alignment. Office extraction is unaffected. With tab_id, only the selected tab is rendered.
`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

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

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"
```

Changed2 schema fields changedv1.27.0Sep 18, 2026

addedInput schema / properties / preserve_context

Added value: +{
+  "default": false,
+  "description": "Include readable semantic annotations for native Docs.\nDefaults to False to retain index alignment. Office extraction is\nunaffected. With tab_id, only the selected tab is rendered.",
+  "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 returned with no tab separator,\nso the content stays index-aligned with that tab. When omitted, every\ntab is returned separated by \"--- TAB: ... ---\" markers."New value: +"Optional ID of a single tab to read (from inspect_doc_structure).\nWhen given, only that tab's content is returned with no tab separator,\nso the default output stays index-aligned with that tab. When\nomitted, every tab is returned with \"--- TAB: ... ---\" markers."

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 returned with no tab separator,\nso the content stays index-aligned with that tab. When omitted, every\ntab is returned separated by \"--- TAB: ... ---\" markers."
+}

Changed11 schema fields changedv1.0.1Jul 31, 2026

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

removedInput schema / properties / docs_service

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

addedInput schema / properties / document_id / description
```
Added value: +"ID of the Google Doc (or full URL)"
```
removedInput schema / properties / document_id / title
```
Removed value: -"Document Id"
```

removedInput schema / properties / drive_service

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

addedInput schema / properties / suggestions_view_mode

Added value: +{
+  "default": "DEFAULT_FOR_CURRENT_ACCESS",
+  "description": "How to render suggestions in the returned content:\n- \"DEFAULT_FOR_CURRENT_ACCESS\": Default based on user's access level\n- \"SUGGESTIONS_INLINE\": Suggested changes appear inline in the document\n- \"PREVIEW_SUGGESTIONS_ACCEPTED\": Preview as if all suggestions were accepted\n- \"PREVIEW_WITHOUT_SUGGESTIONS\": Preview as if all suggestions were rejected",
+  "type": "string"
+}

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: -[
-  "drive_service",
-  "docs_service",
-  "user_google_email",
-  "document_id"
-]New value: +[
+  "user_google_email",
+  "document_id"
+]

removedInput schema / title

Removed value: -"get_doc_contentArguments"

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

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context beyond annotations: index alignment with U+FFFC placeholders, body starts at index 1, offset mapping (n+1), table/tab separator interleaving, preserve_context behavior, and exclusions (comments, revision history, exact visual layout, chip details hidden by API). This is rich, non-obvious behavior that an agent needs to know before calling.

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 well-structured with clear sections and front-loaded purpose. It is longer than average, but every sentence earns its place by explaining non-obvious behavior (index alignment, preserve_context semantics, exclusions). The only minor deduction is that the index-alignment explanation is dense and could be slightly tightened, but it is not redundant.

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?

Given the tool's complexity (5 params, output schema present, multiple file types, index-alignment behavior), the description is complete. It covers what is returned, how alignment works, when to use preserve_context, what is excluded, and how to route to get_doc_as_markdown. The output schema exists, so return values need not be described in prose. Nothing an agent needs to call this correctly is missing.

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 description coverage is 100%, so the schema already documents all 5 parameters. The description adds meaning beyond the schema by explaining the behavioral implications of preserve_context (readable semantic annotations, plain text not Markdown, offsets not usable as editing indices) and tab_id (index-aligned with that tab, no tab separator). It also clarifies document_id accepts full URL. This goes beyond the baseline 3 for full coverage.

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 clearly states the tool retrieves content of a Google Doc or Drive file (like .docx) identified by document_id, and distinguishes between native Docs (via Docs API) and Office files (via Drive API). It also differentiates from sibling get_doc_as_markdown by noting that tool is for formatting/comments. The verb 'retrieves' plus resource and scope is specific and 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 explains when to use this tool vs alternatives: 'Use get_doc_as_markdown for formatting or comments.' It also provides detailed guidance on when to set preserve_context=True and warns that offsets in that mode must not be used as editing indices. It explains the default index-aligned behavior and how to use tab_id for single-tab reads, giving clear context for choosing this tool over siblings.

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

Deploy Server