[FEATURE] Gmail MCP Connector: Add file attachment support to gmail_create_draft and add gmail_send_draft tool

Open 💬 9 comments Opened Feb 25, 2026 by maurorozco

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

The Gmail MCP connector in Cowork mode does not support attaching files when creating email drafts. The gmail_create_draft tool only accepts to, subject, body, cc, bcc, and contentType parameters — there is no parameter for file attachments. Additionally, there is no gmail_send_draft tool to send a previously created draft.

The workflow breaks down as follows:

  1. gmail_create_draft successfully creates the draft with the correct recipients, subject, and body
  2. 2. No attachment parameter exists — the tool cannot attach files that Cowork has generated (e.g., .docx, .pdf, .xlsx reports)
  3. 3. No gmail_send_draft tool — even if the draft is created, Cowork cannot programmatically send it

This forces users to fall back to browser automation (Claude in Chrome) to manually navigate Gmail, find the draft, click the attach button, and upload the file — which is unreliable and slow. In practice, the user ends up having to attach the file and send the email manually, defeating the purpose of the automation.

Reproduction Steps:

  1. In Cowork mode, create a file (e.g., a .docx report)
  2. 2. Ask Claude to email the file via Gmail to a recipient
  3. 3. Claude creates the draft via gmail_create_draft but cannot attach the file
  4. 4. Claude attempts to use Chrome automation as a fallback, but injecting files into Gmail's file input via JavaScript is complex, unreliable, and often times out

This is a significant gap in Cowork's end-to-end workflow capability. One of Cowork's core value propositions is automating tasks like "research X, create a report, and email it to Y." Without attachment support, the last step always requires manual intervention.

Proposed Solution

Add an attachments parameter to gmail_create_draft and create two new tools:

1. Update gmail_create_draft

Add an optional attachments parameter:

gmail_create_draft:
  - to (required)
  -   - subject (required)
  -   -   - body (required)
  -   -   -   - cc (optional)
  -   -   -   -   - bcc (optional)
  -   -   -   -   -   - contentType (optional)
  -   -   -   -   -   -   - attachments (optional): array of {filename: string, base64Content: string, mimeType: string}
  -   -   -   -   -   -   - ```
### 2. New `gmail_send_draft` tool

gmail_send_draft:

  • draftId (required): The draft ID returned by gmail_create_draft
  • ```

3. New gmail_send_message tool (optional but ideal)

A convenience tool for direct sending without creating a draft first:

gmail_send_message:
  - to (required)
  -   - subject (required)
  -   -   - body (required)
  -   -   -   - cc (optional)
  -   -   -   -   - bcc (optional)
  -   -   -   -   -   - contentType (optional)
  -   -   -   -   -   -   - attachments (optional): array of {filename: string, base64Content: string, mimeType: string}
  -   -   -   -   -   -   - ```
The Gmail API already supports all of these operations via `messages.send` and `drafts.send`, so the backend implementation should be straightforward.

### Alternative Solutions

The current workaround is to use Claude in Chrome (browser automation) to manually navigate Gmail, find the draft, click the attach button, and upload the file. However, this approach is:

1. **Unreliable** — injecting files into Gmail's file input via JavaScript is complex and often fails due to Gmail's dynamic DOM and security restrictions
2. 2. **Slow** — the multi-step browser automation process (navigate, find draft, click attach, inject base64 file) can take several minutes and often times out
3. 3. **Fragile** — depends on Gmail's UI structure which can change at any time
In practice, users end up having to manually attach files and send the email themselves, which defeats the purpose of the Cowork automation workflow.

### Priority

High - Significant impact on productivity

### Feature Category

MCP server integration

### Use Case Example

Real scenario that just happened:

1. User asks Claude in Cowork mode: "Research treatment options for shoulder arthritis for my elderly mother and create a detailed medical report as a Word document"
2. Claude performs web research, gathers information from medical sources, and generates a comprehensive .docx report
3. User says: "Great, now email that report to my father at dad@example.com"
4. Claude uses `gmail_create_draft` to create a draft with the correct recipient, subject, and HTML body — this works perfectly
5. **Claude cannot attach the .docx file** because `gmail_create_draft` has no `attachments` parameter
6. Claude attempts to use Chrome browser automation to open Gmail, find the draft, and manually attach the file — this is slow, unreliable, and fails
7. User has to manually open Gmail, find the draft, attach the file, and send it themselves

**With the proposed feature:**
- Step 5 would use `gmail_create_draft` with `attachments: [{filename: "report.docx", base64Content: "...", mimeType: "application/vnd.openxmlformats-officedocument.wordprocessingml.document"}]`
- Step 6 would use `gmail_send_draft` with the returned `draftId`
- The entire workflow completes automatically end-to-end

### Additional Context

- **Environment:** Claude Desktop (Cowork mode), Gmail MCP Connector, macOS
- **Gmail API support:** The Gmail API already supports file attachments via multipart MIME messages (`messages.send`) and sending drafts (`drafts.send`), so the backend implementation should be straightforward
- **Related tools that already exist:** `gmail_create_draft`, `gmail_search_messages`, `gmail_read_message`, `gmail_read_thread`, `gmail_list_drafts`, `gmail_get_profile`
- **Current `gmail_create_draft` response:** Already returns `draftId` and `messageId`, so `gmail_send_draft` could use the existing `draftId` directly

View original on GitHub ↗

This issue has 9 comments on GitHub. Read the full discussion on GitHub ↗