Gmail MCP create_draft: description says attachments are unsupported, but the schema documents them and the call succeeds

The mcp__claude_ai_Gmail__create_draft tool carries a stated limitation that contradicts its own input schema and its observed behaviour.

The contradiction

The tool description ends with:

Limitation: Creating drafts with attachments is not supported yet.

But the same tool's input schema fully documents an attachments array, with a detailed Attachment definition covering content (base64, required), filename, mimeType, inline, and id, plus a documented 25MB combined size limit and advice to use Drive for larger files. The sibling mcp__claude_ai_Gmail__update_draft exposes the identical attachments schema and carries no such limitation note.

Observed behaviour

Calling create_draft with an attachment did not error:

{
  "to": ["<redacted>"],
  "subject": "[test] attachment support probe",
  "body": "...",
  "attachments": [
    {"content": "dGVzdA==", "filename": "probe.txt", "mimeType": "text/plain"}
  ]
}

Response:

{"id":"r6746207412576979069"}

The draft was created and is visible via list_drafts.

What I could not verify

I could not confirm that the attachment is actually persisted on the draft, so I am not claiming the feature definitely works end to end. list_drafts returns no attachment metadata, and get_message needs a message ID that is not exposed for an unsent draft. So the accurate statement is narrower: the parameter is accepted and the call succeeds, rather than silently 400-ing as the description implies it would.

Either way the documentation and the schema disagree, and one of them needs correcting:

• If attachments are supported, the limitation sentence should be removed.
• If they are not, the call should fail with a clear error rather than returning a draft ID, and ideally the attachments field should not be advertised in the schema at all.

Why it matters

The description is what an agent reads when deciding whether an approach is viable. As written, it steers the model away from attachments entirely, toward workarounds like inlining base64 into the body or uploading to Drive, which are worse outcomes if the feature actually works. Conversely, if the parameter is silently ignored, an agent could report to a user that a file was attached when it was not, which is a correctness problem rather than a cosmetic one.

Environment

• Claude Code, claude.ai Gmail MCP connector
• Tools: mcp__claude_ai_Gmail__create_draft, mcp__claude_ai_Gmail__update_draft, mcp__claude_ai_Gmail__list_drafts

Unrelated minor note

create_draft marks every field optional in its schema, including recipients, but rejects a call with no recipient at runtime:

At least one recipient (To, Cc, or Bcc) must be specified.

Making that constraint visible in the schema description would save a round trip.