Case study · Limited connector
In-thread Gmail drafting that native connections cannot do
A professional-services team wanted Claude to draft replies inside the original email thread, not beside it. We built full read-write Gmail with in-thread drafting, label management, and a gated send.
How do you get Claude to draft a Gmail reply inside the thread?
Gmail in-thread drafting with Claude requires a full read-write Gmail connector, not a read-only or compose-only connection. We built one that reads the whole thread, attaches the draft to it with the correct recipients and quoted history, manages labels, and keeps send behind a human confirmation.
The situation
The team (a professional-services firm, anonymized here) lived in Gmail. They wanted Claude to help clear a busy shared inbox by reading a thread and drafting a reply they could review and send. The default connection they started with could read mail and compose a brand-new message, but it could not place a draft back inside the original thread. Every reply came out as a fresh email with no quoted history, the wrong subject, and recipients they had to re-add by hand. It also could not manage labels, so triage stayed manual. The connector was limited in exactly the place the work happened: inside the thread.
How does Claude draft a Gmail reply inside the thread?
Drafting a reply inside the thread works through a full read-write custom MCP connector that reads the whole thread, then creates a draft attached to that same thread with the original recipients, subject, and quoted history carried over. Labels are applied or changed in the same step, and sending stays behind an explicit human confirmation.
We built a full read-write custom MCP connector for Gmail with separated read and write tools. Read tools pull the full thread, search the mailbox, and list labels. Write tools create and update drafts attached to the correct thread (carrying over recipients, subject, and quoted history) and apply, change, or remove labels. Sending is a separate, gated action: drafts flow freely so the team edits in Gmail, while the actual send requires an explicit human-in-the-loop confirmation. The connector authenticates as the user's own Google account, so it never grants Claude more access than the person already has.
What Claude can now do
- Read a full thread and draft a reply that lands inside that same thread, not in a separate new message.
- Match the thread's recipients, subject, and quoted history automatically so the draft is ready to review.
- Create and update drafts freely, so the team edits in Gmail before anything goes out.
- Apply, change, and remove labels to triage a thread (for example, move it to a client or follow-up label).
- Search the mailbox by sender, subject, or label to pull the right thread before drafting.
- Send only after an explicit human confirmation, so Claude never sends an email on its own.
The outcome
Replies now land where the conversation already lives. The team asks Claude to read a thread and draft a response, reviews it in Gmail with full quoted history and the right recipients in place, and sends when they are happy. Triage that used to be manual (labeling and sorting threads) now happens in the same conversation.
In-thread drafting
Replies are composed inside the original thread, with the right recipients and full quoted history, instead of in a separate window the team has to reconcile by hand.
Send stays gated
Claude labels and triages threads in the same conversation, while every outbound send waits for a person to review and confirm it.
Want the same for your inbox? See what full read-write Gmail unlocks on the Gmail connector page.
Frequently asked questions
Why can't a native or default Gmail connection draft inside a thread?
Can Claude send the email, or only draft it?
Does the connector give Claude access to the whole mailbox?
Tell us what you run. We'll build the connector.
Pick your tool, choose what Claude should do, and get an instant scope and price. No call required.