Platform: MCP server used from Claude Code (Windows), email block.
What I was doing: reading a client's reply to my own email through the Macro MCP tools, where the client answered inline / attached a PDF.
1. GetThread strips the part of a reply that carries inline answers. For the reply message, bodyParsed contained only the sender's short sign-off and signature. Everything after the ________________________________ From: ... divider (the quoted original, which is where inline answers live in Outlook-style replies) was dropped. The Gmail API for the same message returns the full plain-text body including the quoted section. Suggest either keeping the quoted section in bodyParsed or exposing a bodyRaw / bodyFull field alongside the parsed one.
2. ReadContent on an email message id errors. ReadContent(documentId=<email message id from GetThread>) returned unable to get the entity access receipt. If email messages are not meant to be readable through ReadContent, the tool description should say so and GetThread should be the complete path (see 1).
3. No way to retrieve attachments. GetThread lists nothing about attachments; the reply in question carried a 6-attachment payload (five inline signature images plus a PDF with the actual answers) and the only way to learn that was via the Gmail API. Feature request: expose attachment metadata (filename, mime type, size, id) on messages in GetThread, and a GetAttachment(messageId, attachmentId) tool (or a download URL) so an agent can read a PDF a client sends.
Repro: any Outlook-originated reply that answers inline below the quoted original, or that carries a PDF attachment. Thread id in my workspace: 01a0a6dc-0c8f-7135-85ff-7687241e1cde (message 01a0abda-b1b3-7533-9bc7-29303f7f4c03).
Related but distinct: #6446 (missing tools) and #5465 (auth headers).
Platform: MCP server used from Claude Code (Windows), email block.
What I was doing: reading a client's reply to my own email through the Macro MCP tools, where the client answered inline / attached a PDF.
1.
GetThreadstrips the part of a reply that carries inline answers. For the reply message,bodyParsedcontained only the sender's short sign-off and signature. Everything after the________________________________ From: ...divider (the quoted original, which is where inline answers live in Outlook-style replies) was dropped. The Gmail API for the same message returns the full plain-text body including the quoted section. Suggest either keeping the quoted section inbodyParsedor exposing abodyRaw/bodyFullfield alongside the parsed one.2.
ReadContenton an email message id errors.ReadContent(documentId=<email message id from GetThread>)returnedunable to get the entity access receipt. If email messages are not meant to be readable throughReadContent, the tool description should say so andGetThreadshould be the complete path (see 1).3. No way to retrieve attachments.
GetThreadlists nothing about attachments; the reply in question carried a 6-attachment payload (five inline signature images plus a PDF with the actual answers) and the only way to learn that was via the Gmail API. Feature request: expose attachment metadata (filename, mime type, size, id) on messages inGetThread, and aGetAttachment(messageId, attachmentId)tool (or a download URL) so an agent can read a PDF a client sends.Repro: any Outlook-originated reply that answers inline below the quoted original, or that carries a PDF attachment. Thread id in my workspace:
01a0a6dc-0c8f-7135-85ff-7687241e1cde(message01a0abda-b1b3-7533-9bc7-29303f7f4c03).Related but distinct: #6446 (missing tools) and #5465 (auth headers).