[BUG] gmail_read_message has now been removed

Found 1 possible duplicate issue:

1. https://github.com/anthropics/claude-code/issues/47847

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

The above issue is not the same issue at all other than the similarity of the MCP not working properly, but they are not the same issue

Confirming this bug from an independent use case. I filed #50298 before noticing #48713 — closing mine as duplicate and +1-ing this one.

My context is different from the flight parser but hits the same root cause: a small business IT admin workflow that monitors 9 servers via daily email health reports. Each server sends a structured report at 07:00–08:00 with [CRIT] / [WARN] / [OK] counts in the body. search_threads correctly returns the thread metadata (and Claude can see that warnings increased from 8 to 12 on one server), but without the email body Claude cannot tell which warnings — making the monitoring workflow essentially blind.

Reproduced today (2026-04-18) on Claude.ai (web), Opus 4.7 model, Gmail connector. get_thread with messageFormat: "FULL_CONTENT" returns identical payload to the default call — only snippet, subject, sender, date, toRecipients. No body, payload, or parts field.

Fully agree with the original request: please restore full body access, either by bringing back gmail_read_message or by making get_thread's FULL_CONTENT behave per its documented spec.

i am not a github expert, but i am bumping this because i am also facing the same problem and it broke all my workflows :(

Follow-up on my 2026-04-18 comment — ran more tests today; the bug behaves inconsistently across messages, and I wanted to share what I observed and what I could NOT verify.

Setup: same as 2026-04-18 (Claude.ai web, Opus 4.7, same Gmail connector, same account). Called get_thread with messageFormat: "FULL_CONTENT" on 6 recent inbox messages.

Result: 2 out of 6 returned a populated plaintextBody field. The other 4 returned only metadata (snippet, subject, sender, date, recipients). No error, no warning — just the field silently absent.

Observed correlation (not confirmed as root cause): the two messages that succeeded were both multipart/alternative messages with a dedicated text/plain part. The four that failed all appear to be single-part text/html messages with no text/plain alternative. I could not inspect the raw MIME from the connector side to confirm this, so the correlation is based only on the typical structure of those senders.

Limits of this report:

• Small sample (n=6).
• No access to the raw payload/parts tree from the connector, so the MIME hypothesis is inferred, not verified.
• I don't know whether the behavior depends on the sender, the message structure, the size, or something else entirely.
• I don't know whether this is a regression introduced in a specific version, or intermittent behavior I happened to observe today.

Net effect is the same as in my 2026-04-18 comment: for a non-trivial share of inbox messages, plaintextBody is not returned at all, so any skill that needs to parse email content is blocked on those messages. The original report from @cheekyjeremy still stands.

Happy to provide more data points if useful.

Gmail MCP can't read my mails with full content last week. And my skill became useless since then. I have to switch to Gemini when I need to read mails.

While it did break my workflows, allowing the chrome MCP allows cowork to go in and process my Gmail that way. Not ideal, but the timeline is more or less the same

Running into a similar issue. Here is the analysis I put together.

Gmail Connector Bug: get_thread returns no body content for HTML-only emails

Summary

The Gmail connector's get_thread tool does not return body content for HTML-only emails. This is a confirmed and reproducible limitation.

---

Test 1: Forwarded HTML-only Email (Works)

Subject: Fwd: [Company]/[App] Training: Call recording and analysis is ready
Sender: user@company.com (forwarded from do-not-reply@gong.io)

Request

get_thread(threadId: "<thread-id>", messageFormat: "FULL_CONTENT")

Result

Returns 7 fields including plaintextBody with the full email body.

Why it works: When the email was forwarded, the sender's email client created a new multipart message that included a proper plaintext MIME part. The connector can read that.

---

Test 2: Original Gong Email (Broken)

Subject: A call with [Company] - shared by [User]
Sender: do-not-reply@gong.io

Request

get_thread(threadId: "<thread-id>", messageFormat: "FULL_CONTENT")

Raw Response

{
  "id": "<thread-id>",
  "messages": [
    {
      "date": "2026-04-23T18:25:04Z",
      "id": "<message-id>",
      "sender": "do-not-reply@gong.io",
      "snippet": "User A shared a call with you via Gong [Company] Training • Apr 22, 2026 • 54 minutes",
      "subject": "A call with [Company] - shared by [User]",
      "toRecipients": ["user@company.com"]
    }
  ]
}

Result: 6 fields only — no plaintextBody, no htmlBody, no body content of any kind.

---

Conclusion

The connector cannot read HTML-only emails. When an email has no plaintext MIME part (as is the case with direct Gong notification emails), get_thread returns only metadata with no body content. There is no htmlBody fallback field.

Expected Behavior

get_thread with messageFormat: "FULL_CONTENT" should return body content for all emails, including HTML-only ones — either via an htmlBody field or by stripping the HTML to plaintext as a fallback.

Workaround

Having the email forwarded by a human creates a new multipart message with a plaintext part that the connector can read. This is not a practical solution.

Additional Context

• The old gmail_read_message tool reportedly returned body content for these same emails
• The search_threads tool correctly returns snippets for HTML-only emails — the issue is specific to get_thread not providing full body content

I am not an expert in this field but would like to share that I have the same issue. And this is part of what Claude explains to me.

I can confirm the issue now. The original session used a tool called gmail_read_message which accepted a messageId and returned the full email body. That tool has been replaced in the updated Gmail connector — the current get_thread tool claims to support FULL_CONTENT but doesn't actually return the body text.
Unfortunately, this is a connector limitation I can't work around with the current tools. Here's what I'd suggest:

So due to getting no update from Anthropic on a fix for this, our company had to move onto alternatives. Recently OpenAI released the ChatGPT agents which also integrate with Gmail and are a perfect drop in replacement for our workflows.

Just a tip for those waiting on an update

I hope they fix this, we had various skills and tasks running in Cowork for our business, all of them now rendered useless.

I think I am also running into this - longer gmail threads are not read fully which makes scheduled task "stay on top of things" useless.

Seeing this on an HTML-only transactional email. get_thread with messageFormat: FULL_CONTENT returns only the 6 metadata fields — no body, no htmlBody, no plaintextBody. The email renders fine in Gmail UI and search_threads returns the snippet correctly, so the connector is reaching the message; get_thread just isn't surfacing the body.

This matches the pattern described by @cheekyjeremy and the HTML-only analysis in the comment above — when there's no plaintext MIME part, the connector appears to return nothing rather than falling back to htmlBody.

Adjacent ask: expose a tool to fetch attachment bytes by attachmentId

Posting here rather than opening a new issue since this thread already covers attachment access in the Gmail connector regression.

In the current claude.ai Gmail connector, get_thread with messageFormat: FULL_CONTENT does return attachmentIds and attachment metadata (filename, mimeType) on messages. What's missing is a companion tool to actually retrieve the attachment bytes — the equivalent of Gmail API users.messages.attachments.get.

Use case. I run a recurring "triage inbox" workflow where Claude reads emails I've labeled, classifies them against an ongoing work tracker, and proposes file-system updates to a markdown-based project. Attachments (PDFs, flowcharts, scoping documents) routinely need to land in a specific project folder on disk. Today the workflow stops at "you'll need to download this manually and drop it in engagements/<slug>/" — which defeats the purpose of automating the triage.

What I'm asking for. A tool roughly shaped like:

get_message_attachment(messageId, attachmentId) -> { data: base64, mimeType, size }
Or any equivalent that lets Claude resolve the attachmentIds already surfaced in get_thread responses. Saving to a local path via the existing file tools would handle the rest.

Why not run a self-hosted Gmail MCP instead. My organization (Google Workspace) restricts personal OAuth apps and Google Cloud project creation, so registering a separate OAuth client for a community Gmail MCP server isn't viable. The claude.ai-hosted connector is the only path that works in this environment — which is why the gap is load-bearing for me rather than just inconvenient.

Precedent: a parallel ask exists for the Microsoft 365 connector in #30533. Same shape of gap, same use case.

Happy to file this as a separate feature request if that's preferable to maintainers — flagging it here first because the regression discussed in this issue already touches attachment access.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.