[BUG] Gmail connector: get_thread with messageFormat=FULL_CONTENT returns only snippet, not full message body

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

The Gmail MCP connector's get_thread tool does not honor the messageFormat: FULL_CONTENT parameter. Regardless of whether FULL_CONTENT is explicitly requested, the response contains only the message snippet (first ~200 chars) without the full body.

This is distinct from (but possibly related to) #47847, where read operations fail entirely — in my case, get_thread succeeds but silently returns a degraded payload.

Note: I am NOT using Claude Code — I am using the Gmail connector from Claude.ai (web interface). I am filing this here because related Gmail connector issues (#47847, #40225, #46206, #48277) have been filed in this repo under the area:mcp / area:integrations labels.

Environment

• Interface: Claude.ai (web)
• Connector: Gmail (native claude.ai integration)
• Model: Claude Opus 4.7
• Date first observed: 2026-04-18

What's working

• search_threads — returns thread metadata correctly (id, subject, sender, date, snippet)
• create_draft / list_drafts / list_labels — not tested today but documented as working

What's not working

• get_thread with messageFormat: FULL_CONTENT → returns identical payload to the default call (only snippet, no body)

Expected Behavior

Per the tool schema documentation:

FULL_CONTENT — Returns all information in "MINIMAL" plus the full body content of each message.

Calling get_thread(threadId=X, messageFormat="FULL_CONTENT") should return the complete message body (plain text or HTML payload), not just the snippet.

Actual Behavior

The response contains only:

• id
• snippet (truncated to ~200 chars)
• subject
• sender
• toRecipients
• date

The full message body is NEVER included, even with messageFormat: FULL_CONTENT explicitly passed.

Example Tool Response (actual output)

Request:

get_thread(
  threadId="19d9f2ec02ec2880",
  messageFormat="FULL_CONTENT"
)

Response (unchanged with or without FULL_CONTENT):

{
  "id": "19d9f2ec02ec2880",
  "messages": [
    {
      "id": "19d9f2ec02ec2880",
      "snippet": "Monitoring Report - TS2025 192.168.10.190 | Report generato: 18/04/2026 08:00 | Finestra analisi: ultime 24h RIEPILOGO GENERALE [CRIT] Alert CRITICI 0 [WARN] Warning 12 [OK] OK 11 SERVIZI CRITICI [OK]",
      "subject": "[WARNING] Monitoring TS2025 - 18/04/2026 08:00",
      "sender": "monitoring-ts2025@example.com",
      "toRecipients": ["..."],
      "date": "2026-04-18T06:02:13Z"
    }
  ]
}

No body, payload, parts, or equivalent field is present in the response object. The actual email body (visible in Gmail UI) contains many lines of monitoring details that are NOT returned by the tool.

Impact

• Any workflow that requires reading email content beyond the first ~200 chars is blocked
• Monitoring / reporting / email-analysis use cases are severely impacted: Claude can see that an email exists but cannot process its content
• Forces users to fall back to manual copy-paste, defeating the purpose of the connector

Troubleshooting already performed

• Verified that messageFormat parameter is accepted (no schema validation error)
• Tried FULL_CONTENT and omitting the parameter entirely — identical result
• Tested across multiple emails (different senders, sizes, MIME types) — same result for all

Hypothesis

The connector backend is likely ignoring the messageFormat parameter and always falling back to a MINIMAL-equivalent response shape. The schema advertises FULL_CONTENT as supported, but the implementation appears not to expand the response payload.

Related Issues

Similar but distinct symptoms:

• #47847 — thread read fails entirely (mine succeeds with partial data)
• #40225 — generic "Tool returned error result"
• #46206 — label_thread missing gmail.modify scope
• #48277 — mcp-proxy.anthropic.com 502 Bad Gateway

All of these were filed in the last ~2 weeks, suggesting a broader Gmail connector reliability regression.

What Should Happen?

Calling get_thread with messageFormat: "FULL_CONTENT" should return the complete email body (plain text, HTML, or MIME parts) in addition to the metadata fields already present in the MINIMAL response.

Specifically, the response should include a field such as body, payload, or parts containing the decoded message content, so that the caller can read and process the email's full text — not just the first ~200 characters that appear in snippet.

The current behavior makes the FULL_CONTENT option effectively a no-op.

Error Messages/Logs

No error message is surfaced. The call succeeds (HTTP 200-equivalent at the MCP layer) but the response payload is silently truncated: the body/payload field is simply absent from the response, regardless of whether `messageFormat: FULL_CONTENT` is passed or omitted.

This is a "silent degradation" failure mode — there is no stack trace or log to attach.

Steps to Reproduce

1. In Claude.ai (web), connect the Gmail connector via Settings → Connectors → Gmail, completing the Google OAuth flow with "View your email messages and settings" scope granted.
2. Ensure there is at least one email in the inbox with body content longer than ~200 characters (any newsletter, monitoring notification, or multi-paragraph email).
3. Ask Claude to list or search for that email — the search_threads tool will return the thread metadata correctly, including a threadId.
4. Ask Claude to read the full content of that email. Claude will call get_thread(threadId="<id>", messageFormat="FULL_CONTENT").
5. Inspect the tool response: the messages[].snippet field is present (~200 chars), but there is NO body, payload, or parts field containing the full message content.
6. Repeat step 4 without the messageFormat parameter — the response is byte-identical, confirming FULL_CONTENT is being ignored.

Minimal reproduction: any email body longer than the Gmail API snippet length (~200 chars) will demonstrate the issue. No special MIME type, attachment, or encoding is required — I reproduced it with plain-text system monitoring emails.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

N/A (Claude.ai web — not Claude Code)

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Note on template fit: this bug report is about the Gmail connector accessible from Claude.ai (web interface), not Claude Code CLI. The fields "Claude Code Version", "Platform", "Operating System" and "Terminal/Shell" are required by the template but not fully applicable to a web-connector server-side bug.

The bug is reproducible from any OS/browser because it is a server-side defect in the Gmail MCP connector response serialization, not a client-side issue.

Filing here (repo anthropics/claude-code) per precedent set by issues #47847, #40225, #46206, and #48277 — all of which concern the same Gmail MCP connector and use the same area:mcp / area:integrations labels.

Suggested fix direction:
Inspect the connector's get_thread handler and verify that when messageFormat == "FULL_CONTENT", the underlying Gmail API call uses format=full (not format=metadata or format=minimal), and that the decoded payload.parts[].body.data (Base64URL) is included in the MCP response schema.

Happy to provide additional tool-call/response pairs if useful for debugging.