[BUG] Gmail connector: create_draft no longer accepts threadId — all reply drafts are orphaned in the Drafts folder

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

The Gmail connector's create_draft tool no longer accepts a threadId parameter. As a result, every draft created via the tool lands as a standalone entry in the Drafts folder instead of attaching to the original email thread. For any automation that creates reply drafts (scheduled inbox-processing tasks, assistant workflows, etc.), this means drafts are orphaned and the user has to manually find each one in Drafts and re-attach it to the correct thread before sending — or re-draft entirely inside Gmail.

Environment

• Product: Claude desktop app, Cowork mode
• Connector: Gmail (Anthropic-managed, endpoint gmailmcp.googleapis.com/mcp/v1)
• OS: macOS
• Observed: at least the last 4–5 days

Evidence

Current create_draft tool schema (retrieved via the session's deferred-tool schema introspection):

{
  "name": "create_draft",
  "description": "Creates a new draft email in the authenticated user's Gmail account.",
  "parameters": {
    "properties": {
      "bcc": { "type": "array", "items": { "type": "string" } },
      "body": { "type": "string" },
      "cc":  { "type": "array", "items": { "type": "string" } },
      "htmlBody": { "type": "string" },
      "subject": { "type": "string" },
      "to": { "type": "array", "items": { "type": "string" } }
    }
  }
}

Note: no threadId parameter. The underlying Gmail API users.drafts.create method does accept a message.threadId field, so the capability exists server-side — it is simply no longer exposed through the connector's tool surface.

Expected behavior

create_draft should accept an optional threadId parameter. When provided, the created draft should be attached to that Gmail thread (equivalent to clicking "Reply" in the Gmail web UI) and appear inline in the thread timeline labeled "Draft."

Actual behavior

• create_draft has no threadId parameter in its schema; passing one is rejected or silently ignored.
• Every draft is created as a standalone message, assigned its own fresh thread ID by Gmail, and appears only in the Drafts folder — not inline in the original conversation.
• The user must manually locate each orphan draft in the Drafts folder, delete it, and recreate the reply inside Gmail to recover the in-thread association before sending.

Impact

• Any user-defined skill or workflow that relies on gmail_create_draft with threading is silently broken. The drafts are created, but their placement is wrong.
• The daily inbox-processing workflow I run is producing ~10–30 orphan drafts per day. Each requires manual cleanup.
• This compounds with #47847 (read-side failures) to leave the Gmail connector with a substantially narrower effective feature set than it had earlier in 2026.

Is this a regression?

Yes. Draft-to-thread attachment previously worked. Skills and documentation in the wild still reference passing threadId to create_draft, indicating the parameter was part of the tool's prior contract.

Related issues

• #47847 — Gmail connector: thread search and message reading fail despite correct OAuth scopes (read-side regression; this report documents a companion write-side regression)
• #46206 — Claude for Gmail connector lacks gmail.modify scope (closed as duplicate; shows the broader scope narrowing affecting the same connector)

Together, these suggest the Gmail connector's tool surface and/or OAuth scope set has been materially narrowed in the last several weeks without a corresponding changelog entry.

What Should Happen?

create_draft should accept threadId and attach the created draft to the specified thread, as it did previously. The Gmail API supports this natively; the fix is on the connector / tool-schema side.

Steps to Reproduce

1. Connect the Gmail connector via Claude desktop (OAuth flow).
2. Call create_draft with to, subject, htmlBody. Attempt to include threadId.
3. Observe: threadId is not a recognized parameter in the tool schema.
4. Open Gmail in a browser. Navigate to the thread the draft was meant to reply to.
5. Observe: no draft appears in the thread timeline.
6. Navigate to the Drafts folder.
7. Observe: the draft is present as a standalone entry, not associated with the original thread.

Is this a regression?

Yes, this worked in a previous version.

Last Working Version

Not precisely known. Skill code written against this connector earlier in 2026 assumes threadId is supported, and drafts were arriving in-thread through at least early-to-mid April 2026.

Claude Model

Claude Opus 4.6 (Cowork mode default)

Platform

Claude desktop app (Cowork mode)

Operating System

macOS

Additional Information

Happy to provide session logs or a minimal reproducer. The regression appears to be entirely server-side on the Anthropic-hosted Gmail MCP (gmailmcp.googleapis.com/mcp/v1) — no client-side configuration can restore the parameter.

What Should Happen?

create_draft should accept threadId and attach the created draft to the specified thread, as it did previously. The Gmail API supports this natively; the fix is on the connector / tool-schema side.

Error Messages/Logs

Steps to Reproduce

1. Connect the Gmail connector via Claude desktop (OAuth flow).
2. Call create_draft with to, subject, htmlBody. Attempt to include threadId.
3. Observe: threadId is not a recognized parameter in the tool schema.
4. Open Gmail in a browser. Navigate to the thread the draft was meant to reply to.
5. Observe: no draft appears in the thread timeline.
6. Navigate to the Drafts folder.
7. Observe: the draft is present as a standalone entry, not associated with the original thread.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Not precisely known. Skill code written against this connector earlier in 2026 assumes threadId is supported, and drafts were arriving in-thread through at least early-to-mid April 2026.

Claude Code Version

Claude desktop app (Cowork mode)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_