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

Get Drive File Content

get_drive_file_content

Read-onlyIdempotent

Retrieve and extract readable content from a Google Drive file by ID, including Docs, Sheets, Slides, Office files, PDFs, and images, so you can inspect or process file data without manual downloads.

Instructions

Retrieves the content of a specific Google Drive file by ID, supporting files in shared drives.

• Native Google Docs, Sheets, Slides → exported as text / CSV. • Office files (.docx, .xlsx, .pptx) → unzipped & parsed with std-lib to extract readable text. • PDFs → text extracted with pypdf when possible; scanned/image-only PDFs fall back to a download hint. • Images (PNG, JPEG, GIF, WebP) → returned as MCP image content after the metadata header. SVG → returned as its markup; raster images it embeds as base64 are attached as image content, numbered to match their place in the markup. BMP and TIFF → base64 text, or a download hint when over the default page size. • Any other file → downloaded; tries UTF-8 decode, else notes binary.

Input Schema

Name	Required	Description
`offset`	No	Character offset to read on from after a truncated result.
`file_id`	Yes	Drive file ID.
`full_content`	No	Return all content from offset onward in one call instead of a page of the default size.
`user_google_email`	Yes	The user’s Google email address.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv2.3.0Oct 30, 2026

addedInput schema / properties / full_content

Added value: +{
+  "default": false,
+  "description": "Return all content from offset onward in one call\ninstead of a page of the default size.",
+  "type": "boolean"
+}

addedInput schema / properties / offset

Added value: +{
+  "default": 0,
+  "description": "Character offset to read on from after a truncated result.",
+  "type": "integer"
+}

Changed9 schema fields changedv1.0.1Jul 31, 2026

addedInput schema / additionalProperties
```
Added value: +false
```
addedInput schema / properties / file_id / description
```
Added value: +"Drive file ID."
```
removedInput schema / properties / file_id / title
```
Removed value: -"File Id"
```

removedInput schema / properties / service

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

addedInput schema / properties / user_google_email / description
```
Added value: +"The 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",
-  "file_id"
-]New value: +[
+  "user_google_email",
+  "file_id"
+]

removedInput schema / title

Removed value: -"get_drive_file_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

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so safety is covered; the description goes further with genuinely useful behavior: export vs. unzip-and-parse vs. pypdf extraction, image returned as MCP image content, SVG base64 sub-images numbered to markup, and explicit fallbacks ('download hint') when extraction or page size fails. It does not mention error/failure modes (not found, permission denied) or what happens when full_content exceeds limits, keeping it short of a 5.

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 core action is front-loaded in sentence one, then a scannable bullet list keyed by file type. Every bullet carries a distinct, non-redundant fact. Slight deduction for length and for awkward line-wrapped continuations inside the bullets.

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 read tool with an output schema, rich annotations, and fully documented parameters, the description covers the one thing structured fields cannot: which file types are convertible and what the agent actually gets back for each. Missing error/auth details are minor given the annotation and output-schema coverage.

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 schema already carries offset, full_content, file_id and user_google_email semantics; baseline 3 applies. The description adds only indirect context via the repeated notion of 'default page size' and 'download hint', which hints at pagination but gives no guidance on choosing offset vs. full_content.

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?

The first sentence gives a specific verb and resource ('Retrieves the content of a specific Google Drive file by ID') plus a scope note about shared drives. The type-by-type breakdown makes the tool's remit unmistakable. It loses a point for never naming the adjacent siblings (get_doc_content, get_doc_as_markdown, get_drive_file_download_url) that an agent must choose between for Docs or link-style access.

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

Usage Guidelines3/5

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

Usage is only implied: the bullet list signals this tool spans Docs/Sheets/Slides/Office/PDF/images, letting an agent infer it can be used generically. There is no explicit statement of when to prefer this over get_doc_content, get_doc_as_markdown, or get_drive_file_download_url, and no prerequisites are stated beyond the email parameter. Adequate but leaves real routing ambiguity in a very crowded file/doc toolset.

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

Deploy Server