Gmail MCP has no get_attachment tool: status and workaround?
The official Gmail MCP connector exposes search_threads, get_thread, create_draft, create_label, list_drafts, and list_labels, but no tool to download message attachments. Calling get_thread with messageFormat: FULL_CONTENT returns attachment content as inline base64, and for a multi-MB PDF the response exceeds the LLM's 25,000-token read limit so an agent cannot process the PDF. The issue proposing a get_attachment tool was closed as NOT_PLANNED — what is the status and is there a workaround?
Originally asked on GitHub: https://github.com/modelcontextprotocol/servers/issues/4122
2 answers
Status: the issue was closed as NOT_PLANNED. On 2026-09-29 a maintainer explained that the modelcontextprotocol/servers repository contains only the seven MCP reference servers (everything, filesystem, memory, sequentialthinking, fetch, git, time), and the Gmail MCP connector is not part of that repo. Feature requests for it should be filed against the client, connector, or product that ships it. No get_attachment tool was added here as a result of this thread.
The blocker is real: get_thread with messageFormat: FULL_CONTENT returns attachment content as inline base64, and a multi-MB PDF pushes the response past the LLM's 25,000-token read limit, so the agent can confirm that an attachment exists but cannot read its content.
Workaround suggested in the thread (comment 2): have the agent label the Gmail thread with 'DriveUpload'; run a custom Google Apps Script that uploads attachments from labeled emails to Google Drive; then have the agent read the files using the Drive connector's read_file_content tool. The author published the script at github.com/LSRCT/Gmail-MCP-Attachments/ and called it a dirty workaround for now, so it is only confirmed by the author's own use.
Comment 3 proposed a design (not implemented) if you build your own connector: implement only get_attachment with a saveToPath parameter, require a server configuration such as --allowed-download-dir so the agent can only write to a pre-approved directory, and enforce a strict size limit (around 5 MB) for inline base64 returns, with an error message guiding the agent to saveToPath for larger files.
Security note: any saveToPath implementation should restrict file writes to a pre-approved directory so the agent cannot write arbitrary files on the host.
Did this work for you?What @LSRCT tried on GitHub (Outcome unclear)
Suggested workaround: have the agent label the Gmail thread with 'DriveUpload', run a custom Google Apps Script that uploads attachments from labeled emails to Google Drive, then read the files via the Drive connector's read_file_content tool. The script was published at github.com/LSRCT/Gmail-MCP-Attachments/. The author described it as a dirty workaround for now, so it is only confirmed by the author's own use.
Did this work for you?
Related questions
- mcp-server-fetch: 'AnyUrl' object has no attribute 'decode' error
- Does the official MCP Postgres example validate SQL before executing it?
- How to fix UTF-8 Japanese text corruption/crash in mcp-server-sqlite with Claude Desktop on Windows?
- MCP Knowledge Graph Memory Server fails with ${workspaceFolder} in MEMORY_FILE_PATH
- npx @modelcontextprotocol/server-filesystem: ERR_MODULE_NOT_FOUND for zod-to-json-schema