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

Get Gmail Message Content

get_gmail_message_content

Read-onlyIdempotent

Retrieve a Gmail message’s subject, sender, recipients, and body as paginated JSON, with options for raw HTML or complete export when the body exceeds truncation limits.

Instructions

Retrieves the full content (subject, sender, recipients, body) of a specific Gmail message.

Set page_offset=0 to read the complete rendered body, excluding attachments and attached messages, as JSON pages of at most page_size characters. Follow next_offset until complete=true, passing body_sha256 as expected_sha256 and keeping body_format and include_links unchanged.

Bodies are returned inline and truncated at 20,000 characters. Set full=True to get the complete, untruncated message instead: it is exported to storage and the response carries a short-lived download URL (HTTP transport) or file path (stdio transport) rather than the body, so large messages never stream through the model context. Stateless deployments without GCS staging have no storage, so there full=True returns the untruncated body inline; with GCS staging configured it returns a signed download URL like any other HTTP deployment.

Input Schema

Name	Required	Description	Default
`full`	No	When True, return the COMPLETE untruncated message: saved to storage and referenced by download URL/file path instead of the body text. In stateless mode without GCS staging, the body is returned inline; with GCS staging, a signed download URL is returned. Use for messages large enough to hit the truncation limit, or when byte-exact fidelity is needed (pair with body_format='raw' for a .eml export).
`format`	No	Message format. "full" (default) includes the body and attachments, "metadata" only headers.	full
`page_size`	No	Maximum body characters per page, between 1 and 20,000.
`message_id`	Yes	The unique ID of the Gmail message to retrieve.
`body_format`	No	Body output format (only applies when format='full'). 'text' (default) returns plaintext (HTML converted to text as fallback). 'html' returns the raw HTML body as-is without conversion. 'raw' fetches the full raw MIME message and returns the base64url-decoded content.	text
`page_offset`	No	Character offset in the complete rendered body. Start at 0 and follow next_offset.
`include_links`	No	When True, append a LINKS section listing the http(s) URLs from the HTML body that the text output omits. Only applies to body_format='text'.
`expected_sha256`	No	Optional previous body_sha256; rejects changed content.
`include_headers`	No	When False, omit the Subject/From/To/Date header summary (attached messages' too), and with full=True name the export after the message ID. Requires format='full'; body_format='raw' is only allowed when the raw message is exported to a file.
`user_google_email`	Yes	The user's Google email address. Required.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv2.3.0Oct 30, 2026

addedInput schema / properties / expected_sha256

Added value: +{
+  "default": null,
+  "description": "Optional previous body_sha256; rejects changed content.",
+  "type": "string"
+}

addedInput schema / properties / page_offset

Added value: +{
+  "default": null,
+  "description": "Character offset in the complete rendered body. Start at 0 and follow next_offset.",
+  "minimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / page_size

Added value: +{
+  "default": 20000,
+  "description": "Maximum body characters per page, between 1 and 20,000.",
+  "maximum": 20000,
+  "minimum": 1,
+  "type": "integer"
+}

Changed3 schema fields changedv2.2.0Oct 24, 2026

changedInput schema / properties / full / description

Previous value: -"When True, return the COMPLETE untruncated message: saved to local storage and referenced by download URL/file path instead of the body text, or inlined in the response when the server has no file storage (stateless mode). Use for messages large enough to hit the truncation limit, or when byte-exact fidelity is needed (pair with body_format='raw' for a .eml export)."New value: +"When True, return the COMPLETE untruncated message: saved to storage and referenced by download URL/file path instead of the body text. In stateless mode without GCS staging, the body is returned inline; with GCS staging, a signed download URL is returned. Use for messages large enough to hit the truncation limit, or when byte-exact fidelity is needed (pair with body_format='raw' for a .eml export)."

addedInput schema / properties / include_headers

Added value: +{
+  "default": true,
+  "description": "When False, omit the Subject/From/To/Date header\nsummary (attached messages' too), and with full=True name the export\nafter the message ID. Requires format='full'; body_format='raw' is only\nallowed when the raw message is exported to a file.",
+  "type": "boolean"
+}

addedInput schema / properties / include_links

Added value: +{
+  "default": false,
+  "description": "When True, append a LINKS section listing the http(s) URLs from the HTML body that the text output omits. Only applies to body_format='text'.",
+  "type": "boolean"
+}

Changed2 schema fields changedv1.28.0Sep 24, 2026

changedInput schema / properties / body_format / description

Previous value: -"Body output format. 'text' (default) returns plaintext (HTML converted to text as fallback). 'html' returns the raw HTML body as-is without conversion. 'raw' fetches the full raw MIME message and returns the base64url-decoded content."New value: +"Body output format (only applies when format='full'). 'text' (default) returns plaintext (HTML converted to text as fallback). 'html' returns the raw HTML body as-is without conversion. 'raw' fetches the full raw MIME message and returns the base64url-decoded content."

addedInput schema / properties / format

Added value: +{
+  "default": "full",
+  "description": "Message format. \"full\" (default) includes\nthe body and attachments, \"metadata\" only headers.",
+  "enum": [
+    "full",
+    "metadata"
+  ],
+  "type": "string"
+}

Changed11 schema fields changedv1.0.1Jul 31, 2026

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

addedInput schema / properties / body_format

Added value: +{
+  "default": "text",
+  "description": "Body output format. 'text' (default) returns plaintext (HTML converted to text as fallback). 'html' returns the raw HTML body as-is without conversion. 'raw' fetches the full raw MIME message and returns the base64url-decoded content.",
+  "enum": [
+    "text",
+    "html",
+    "raw"
+  ],
+  "type": "string"
+}

addedInput schema / properties / full

Added value: +{
+  "default": false,
+  "description": "When True, return the COMPLETE untruncated message: saved to local storage and referenced by download URL/file path instead of the body text, or inlined in the response when the server has no file storage (stateless mode). Use for messages large enough to hit the truncation limit, or when byte-exact fidelity is needed (pair with body_format='raw' for a .eml export).",
+  "type": "boolean"
+}

addedInput schema / properties / message_id / description

Added value: +"The unique ID of the Gmail message to retrieve."

removedInput schema / properties / message_id / title
```
Removed value: -"Message 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. Required."
```
removedInput schema / properties / user_google_email / title
```
Removed value: -"User Google Email"
```

changedInput schema / required

Previous value: -[
-  "service",
-  "message_id",
-  "user_google_email"
-]New value: +[
+  "message_id",
+  "user_google_email"
+]

removedInput schema / title

Removed value: -"get_gmail_message_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.1/5.0

Behavior5/5

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

Annotations already cover read-only, idempotent, non-destructive, and open-world behavior, but the description adds substantial context: attachments and attached messages are excluded, bodies are truncated at 20,000 characters, paging uses offsets and hash validation, and full=True switches to storage with either a short-lived download URL or file path depending on deployment. It also discloses the stateless-without-GCS fallback where full=True returns the body inline.

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 front-loaded with purpose, then covers paging, truncation, and full-export behavior. Its length is justified by the tool's stateful paging and deployment-dependent export modes, though some of the truncation and full=True behavior is repeated from the schema.

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, 10 parameters, rich annotations, and output schema, the description is complete enough: it explains paging, truncation, full-message export, storage/download-URL behavior, and stateless deployment behavior. Return values themselves are left to the output schema, so no essential context 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 individual parameter meanings are already well documented in the schema. The description still adds value by explaining cross-parameter workflow: start page_offset at 0, follow next_offset until complete, pass body_sha256 as expected_sha256, and keep body_format and include_links unchanged across pages.

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 verb and resource: retrieving full content of a specific Gmail message, including subject, sender, recipients, and body. The purpose is clear, but the description does not explicitly differentiate this tool from siblings such as get_gmail_messages_content_batch, get_gmail_thread_content, get_gmail_attachment_content, or search_gmail_messages.

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?

Provides operational usage guidance for paging via page_offset/next_offset and for full=True when the message is large or byte-exact fidelity is needed. However, it does not explicitly say when to use this tool versus sibling tools for batches, threads, attachments, or search, so tool-selection guidance remains implied rather than stated.

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

Deploy Server