[BUG] Gmail connector: get_thread silently truncates long threads — newest messages invisible to the agent (refiled from claude-ai-mcp#239)

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?

The first-party Gmail connector's get_thread tool fails silently on long email threads. When a new reply arrives on a thread with substantial history (roughly 10+ messages), get_thread with messageFormat=FULL_CONTENT either returns a truncated response or returns only one message with no sender, date, or body. The newest message is invisible to the agent.

Consequence: the agent confidently reports "no reply has arrived" when a reply exists. Because the user acts on that answer, this is the worst possible failure mode for email triage — it makes the connector unreliable for exactly the threads that matter most (active, high-traffic conversations).

This was originally filed as anthropics/claude-ai-mcp#239, where a collaborator confirmed the diagnosis but closed it as out of scope for that repo: "What you're describing is in the Gmail connector's tool implementation (get_thread returning a malformed object on long threads), not the client layer this repo covers." Refiling here, where other Gmail connector tool-implementation bugs are tracked (#48713, #47847, #46206).

Note the underlying Gmail REST API (users.messages.list / users.messages.get) handles long threads correctly — the failure is in the connector's tool layer.

What Should Happen?

get_thread should return all messages in the thread — including the most recent — regardless of thread length, or at minimum fail loudly (explicit truncation marker with message count) instead of silently omitting the newest messages.

Proposed fix from the original issue: expose users.messages.list and users.messages.get as MCP tools, enabling message-level access independent of thread length.

Interim workaround (published, open-source): a skill + digest script that reads threads newest-first and forbids "no reply" claims unless the complete thread was verifiably seen: https://github.com/drjhale-arch/gmail-thread-reader

Error Messages/Logs

Steps to Reproduce

1. Have a Gmail thread with 10 or more messages (typical back-and-forth with quoted history).
2. Receive a new reply on that thread.
3. Connect the first-party Gmail connector and call get_thread with messageFormat=FULL_CONTENT on the thread ID.
4. Observe that the newest message does not appear: the response is truncated or contains a single malformed message entry (no sender, date, or body).
5. Ask the agent "has X replied?" — it answers no, although the reply exists in Gmail.

Notes: reproduces regardless of the Gmail "Conversation view" setting. Related symptoms on the same connector: #48713 (get_thread returning metadata only), claude-ai-mcp#203 (HTML bodies dropped), claude-ai-mcp#194 (bodies missing after mid-April 2026 change).

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

N/A — first-party Gmail connector via Claude.ai / Claude Desktop (Cowork); server-side connector defect

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Template fit: this concerns the first-party Gmail connector used from Claude.ai / Claude Desktop (Cowork), not the Claude Code CLI — filed here per precedent (#47847, #46206, #50298 discussion), since connector tool-implementation bugs are tracked in this repo. Version/platform fields below are therefore approximate; the defect is server-side in the connector.

Distinct from #48713 / #50298: those cover body serialization failing for individual (especially HTML-only) messages. This report is about thread-level truncation: on long threads the newest messages are omitted entirely, which flips the agent's answer to "has X replied?" from unknown to a confident, wrong "no". A commenter on #48713 (@dziemid) independently reported the same symptom: "longer gmail threads are not read fully which makes scheduled task 'stay on top of things' useless."

Prior filing: anthropics/claude-ai-mcp#239 — closed by a collaborator as out of scope for the client-layer repo, with the diagnosis confirmed: "get_thread returning a malformed object on long threads."

Open-source workaround demonstrating the issue and the fix direction: https://github.com/drjhale-arch/gmail-thread-reader — reads threads newest-first, digests quoted chains, and enforces that the agent never claims "no reply" without verifiably seeing the complete thread.