v1.8.0

File-path attachment support + auto MIME-encoded Subject

Why

Previously, sending a Gmail message with a PDF attachment required inlining a base64url RFC-2822 blob in the raw tool-call argument. A typical CV at 125KB → ~230KB base64url, which blows past tool-call argument limits. Empirically this blocked every mailto-apply email-with-CV workflow (observed 2026-04-19 on CoPlane, Rinse, Gambit, DHS sends that had to bypass the MCP entirely and POST directly to the Gmail API).

What changed

• create_draft and send_message both accept a new attachments: [{path, filename?, mimeType?}] parameter.
• The server reads each file from disk and builds a multipart/mixed MIME message. Callers pass file paths — no base64 ever touches the tool-call argument boundary.
• MIME type auto-detected from the file extension (pdf, docx, png, etc.); override via mimeType.
• Filename defaults to the basename of the path; override via filename.
• Subject header auto-MIME-encodes per RFC 2047 (=?UTF-8?B?...?=) when non-ASCII characters are present. Fixes em-dash / smart-quote mojibake observed in stored message headers.

Backwards compatibility

None broken. Existing callers using raw (pre-built base64url) or plain-text bodies without attachments behave identically.

Example

{
  "to": ["founders@example.com"],
  "subject": "Application — Charlie Greenman (Austin)",
  "body": "Pitch text here.",
  "attachments": [
    { "path": "/abs/path/to/Charlie-Greenman-CV.pdf" }
  ]
}