Gmail MCP: `create_draft` missing `threadId` parameter — drafts cannot reply to existing threads

Summary

The mcp__claude_ai_Gmail__create_draft tool exposed by the Claude.ai Gmail MCP takes to / cc / bcc / subject / body / htmlBody — but has no threadId / inReplyTo / references parameter. As a result every draft created via this MCP lands as a new Gmail thread; the tool cannot draft a reply onto an existing conversation.

Gmail's underlying REST API (users.drafts.create) already supports this via message.threadId (see Gmail API: Threading outgoing messages). The limitation is purely in the MCP schema — the parameter just isn't plumbed through.

Impact

Any agent-driven workflow that maintains a long-running email conversation with an external correspondent is broken by this gap. Concretely: an Anthropic-adjacent workflow I'm building drafts status updates on private security-report threads (Apache Airflow's security@ list). The skills that drive the workflow can identify the correct threadId from the corresponding tracker, but then cannot hand it to create_draft, so the draft appears as a standalone email. The human recipient sees a fresh thread rather than a reply and (understandably) flags that the conversation history has scattered.

Gmail does not thread outgoing drafts by subject string — a fabricated Re: <subject> body does not attach to any existing thread. threadId is the only mechanism that works.

Observed schema

mcp__claude_ai_Gmail__create_draft(
  to:        string[]    // required
  cc:        string[]    // optional
  bcc:       string[]    // optional
  subject:   string      // optional
  body:      string      // optional
  htmlBody:  string      // optional
)

Requested behaviour

Add an optional threadId parameter (and/or the header-level alternatives inReplyTo / references) that gets forwarded to the underlying Gmail API call. When set, the resulting draft should be attached to the referenced thread and picked up as a reply in the Gmail web UI.

Suggested schema:

mcp__claude_ai_Gmail__create_draft(
  ...,
  threadId:   string     // optional — when set, the draft is attached to this thread
  inReplyTo:  string     // optional — Message-ID to set in the In-Reply-To header
  references: string[]   // optional — additional Message-IDs for the References header
)

threadId alone is enough for Gmail's own clients; inReplyTo + references help non-Gmail clients (Thunderbird, Outlook, Apple Mail) on the recipient side thread the reply correctly.

Workaround today

The only current workaround is to have a human click Reply in the Gmail UI and paste the drafted body in. That defeats the point of an MCP-driven workflow for this use case.

Related

Sibling tools (search_threads, get_thread, label_thread, unlabel_thread) all accept threadId, so the plumbing is clearly available — create_draft is the odd one out.

---

_{Filed via an agent-assisted workflow; happy to provide additional reproduction detail, the actual broken-thread example (a security report relay that split into two conversations because of this gap), or schema-patch test cases on request.}