Feature request: add savePath parameter to download_attachment to avoid base64 overhead

[arndjan]

Problem

When using download_attachment, the tool returns the entire file content as a base64-encoded string in the MCP response. For attachments larger than ~100KB, this creates several problems:

1. The base64 string is enormous — a 3MB docx becomes ~4MB of base64 text in the response
2. MCP clients (like Claude Code) hit token limits and dump the result into a temporary JSON file, requiring additional parsing and decoding steps
3. The round-trip is slow and error-prone — what should be a simple "save this attachment" operation becomes a multi-step base64 extraction and decoding pipeline
4. It wastes context window — the base64 blob consumes significant tokens even for small files

Proposed solution

Add an optional savePath parameter to download_attachment. When provided, the tool writes the decoded attachment directly to that file path and returns only metadata (filename, size, path) instead of the base64 content.

// Current behavior (kept as default for backward compatibility):
download_attachment({ account, id, filename })
// → returns { filename, mimeType, size, base64Content }

// Proposed new behavior when savePath is provided:
download_attachment({ account, id, filename, savePath: "/path/to/save/file.pdf" })
// → writes file to disk, returns { filename, mimeType, size, savedTo: "/path/to/save/file.pdf" }

Prior art

• mcp-email-server already implements this pattern — its download_attachment tool saves directly to a specified path
• The Gmail MCP Server also supports a savePath parameter

Context

This came up while using email-mcp with Claude Code to download meeting documents from email and save them to a Dropbox folder — a very common workflow. The base64 approach turned a 10-second task into a multi-minute ordeal.

[mzealey]

This is also an issue for me. It would enable the default 5mb max attachment size restriction to be lifted which is hitting me at present. would be great to get this capability.