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

Get Doc Content

get_doc_content

Read-onlyIdempotent

Retrieve text content from a Google Doc or Drive file by document ID, including index-aligned native Docs content and extracted text from Office files for reading, formatting, or editing.

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

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. 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 Drive file (or full URL). A Docs URL's ?tab= selects that tab unless tab_id is also specified.
`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

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 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 Drive file (or full URL). A Docs\nURL's ?tab= selects that tab unless tab_id is also specified."

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 default output stays index-aligned with that tab. When\nomitted, every tab is returned with \"--- 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.\nPass \"\" to read every tab of a URL that carries ?tab=. This\nfilters output only: the whole document is 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"
```

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

Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld, yet the description goes well beyond them: index alignment guarantees, U+FFFC placeholder conventions, body offset of 1, the n+1 mapping, and the caveat that alignment breaks at the first table or tab header. It also states what is excluded (comments, revision history, exact visual layout, hidden chip details).

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 purpose and mode split, then the index-alignment contract, then the sibling pointer. It is dense and longer than typical, but nearly every sentence carries operational information; the offset arithmetic paragraph is verbose relative to its value.

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?

For a five-parameter read tool with an output schema, the description covers the non-obvious risks an agent needs: which extraction path applies, the index-offset contract required for follow-up edits, and what content is unavailable. Nothing essential to correct invocation 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 coverage is 100%, so the baseline would be 3, but the description adds genuine meaning for preserve_context (readable link targets and object context at the cost of index alignment) and for how returned offsets map to document indices usable by format_text/delete_text. tab_id and suggestions_view_mode 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?

States a specific verb and resource ('Retrieves content of a Google Doc or a Drive file identified by document_id') and splits the two retrieval paths (Docs API vs Drive download/extract). It also explicitly routes formatting/comment use cases to get_doc_as_markdown, so the agent can separate it from the nearest sibling.

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?

Gives explicit guidance on when to set preserve_context=True and when to prefer get_doc_as_markdown, plus the caveat that offsets from preserve_context output must not be used for editing. It does not distinguish itself from the sibling get_drive_file_content for the '.docx in Drive' case, which is the one remaining routing ambiguity.

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

Deploy Server