[FEATURE] Gmail MCP Connector: Add gmail_modify_labels tool for archiving, labeling, and inbox management

+1 - this is blocking a real workflow for me!

I use Cowork to triage emails into Asana tasks (search for labeled emails → extract action items → create tasks). The workflow works great up until the last step: swapping the Gmail label from "Asana Task" to "Asana Done" so processed emails don't get picked up again on the next run.

More specifically, I label emails in Gmail with "Asana Task" throughout the day as a quick triage step. Then I run a Cowork skill that searches for that label, reads each email, synthesizes an actionable task name and description, infers the correct Asana project, and creates the task. The last step should be swapping the label to "Asana Done" so processed emails don't get picked up on the next run. That step is currently impossible. Without it, the whole workflow requires a full asana/tag search each run, or manual cleanup after every run, which defeats the purpose of automating it.

Without modify_labels, there's no reliable way to close the loop. I've explored every workaround I can think of:

• Tracker files don't persist across Cowork sessions
• Google Drive doc with processed IDs works initially but doesn't scale (grows indefinitely - unnecessary complexity)
• Date-filtered searches (after:YYYY/MM/DD) miss older emails that get labeled after the cutoff, which is a frequent use case, not an edge case. Requires some kind of tracking, mentally other otherwise, to determine appropriate date.
• Third-party Gmail MCPs (Composio, n8n) route email data through external servers, which is a non-starter for anyone handling sensitive client communications
• Local MCP servers (pouyanafisi/gmail-mcp, GongRzhe/Gmail-MCP-Server) have full label support but don't work in Cowork mode

A single endpoint covering archive, read/unread, star, and custom labels unlocks the entire category of email automation workflows that currently dead-end at "now do something with the message."

I agree, the GMAIL MCP needs to support more native GMAIL functions. I run an hourly Cowork scheduled task that scans my inbox, identifies client inquiries, and creates draft replies with pricing and product info specific to my business. It works well, but there's a gap once the drafts are created.

The problem is stale drafts. If a client replies with new information after the task already created a draft in that thread, the draft is now outdated. The task sees an existing draft and skips the thread, so it never gets refreshed. The only fix is for me to manually delete the old draft so the next run picks up the thread again.

This gets worse because Gmail's desktop interface doesn't support multiple drafts per thread. So even if I wanted to work around it by having the task create a second draft, that's not viable on desktop.

What I'd need to fully close the loop:
gmail_delete_draft -- so the task can remove its own stale draft before creating a fresh one
gmail_update_draft -- alternatively, so the task can revise an existing draft in place
gmail_modify_labels (this issue) -- so the task can mark threads as processed, archive handled emails, or swap labels to prevent re-processing

The modify_labels tool described here would also help my workflow directly.

I want to be clear that what I'm doing here isn't complex. This is a straightforward inbox scan and draft reply workflow. I'm not an advanced user building something exotic. But even for this simple use case, these tools are the missing piece. I'd rather not have to set up a third-party Gmail connector just to get delete, update, and label operations that the Gmail API already supports natively. Adding these to the built-in connector would make it more useful for everyone, not just power users.

+1: Critical for Email Triage Workflows

I'm using Claude Cowork to build an automated email inbox triage system and this feature is blocking that workflow entirely.

My Use Case

I want to have Claude analyze my emails and apply temporary triage labels (e.g., flagged_for_deletion, flagged_as_read, needs_response) to mark emails for bulk action. The workflow is:

1. Claude Cowork searches and analyzes emails by sender, content, age, etc.
2. Claude applies triage labels to mark emails for action
3. I execute bulk operations in Gmail (delete, mark as read, archive) on all emails with those labels

Without label-writing capabilities, step 2 is impossible. Claude can read and analyze emails, but cannot mark them for processing, which defeats the purpose of automation.

Impact

• Current state: Email triage via Claude is blocked at the labeling step
• With this feature: Claude Cowork becomes a powerful inbox management tool
• Value: Automated email organization, hands-off bulk cleanup, integration with PKM systems that use labels

Why This Matters for Agentic Workflows

Email triage is a canonical use case for AI agents. Without label-writing, the agent can only analyze emails—it cannot take action to organize them. This is a critical gap in the Gmail connector's capabilities.

The fact that community MCP servers already implement full label management (create, apply, remove, batch operations) shows this is well within scope technically.

This is essential infrastructure for email automation.

What's weird is that clicking on "Refresh tools list" shows the tools! But they disappear on reloading claude. And Cowork complaining that even if it sees the tools the oauth was not approved for the proper scopes

I switched to this service after Claude’s tools weren't cutting it. You can roll your own or pay $10 for his cloud version. https://workspacemcp.com/workspace-mcp-cloud

The four label tools label_thread, unlabel_thread, label_message, unlabel_message do register intermittently in Cowork desktop, but every API call returns additional permissions required because the OAuth scope isn't granted. Worse, the tools then disappear from the runtime within seconds of registration.

Not sure why this hasn't been added yet, would make email organization a breeze.

Not sure why this hasn't been added yet, would make email organization a breeze.

Just use the service I mentioned above or roll your own Gmail MCP. I give up on Anthropic fixing this connector.

+1. Worth noting this gap also applies to the consumer claude.ai Gmail connector, not just Cowork — the read-only tool set in the OP matches what the hosted connector exposes in the consumer app too.

Use case from today: I asked Claude to do an inbox sweep and surface unpaid invoices, expiring subscriptions, and items needing follow-up. Worked beautifully on the read side — surfaced ~6 actionable items I'd have missed. Then asked it to archive the obvious noise it had already classified (newsletters, promo, expired security alerts). Couldn't. The triage took 15 minutes, the manual cleanup took another 15.

This isn't a Cowork-specific gap. It's the entire Gmail connector surface across products. gmail_modify_labels would unlock real value for every Claude user.

Two months open, no assignee — would love to know if this is on the roadmap.

@matuspavliscak Just switch to this service and your good. You can roll your own or pay $10 for his cloud version. https://workspacemcp.com/workspace-mcp-cloud

I've built a local workaround to address this issue.
Repository: https://github.com/tirth97/gmail-modify-mcp
Setup: Follow the repository README to generate your Google Cloud credentials and configure the server. Claude can assist you with the local startup process.

Compatibility: Works exclusively with Claude Chat and the Claude CLI. It does not support Cowork at this time.

If gmail_modify_labels gets added, I’d strongly separate the read triage phase from the write mutation phase in the approval UX.

A small preflight before archive/label/remove-label would prevent the scary failure mode where “summarize unread mail” silently becomes “mutate the inbox”:

• account / mailbox identity
• OAuth scope being used (gmail.modify, not just read)
• source query or thread ids, with generated-at time
• thread/message count and max mutation count
• exact label changes: add/remove/archive/mark-read
• dry-run summary of examples, with subjects/senders redacted if needed
• undo/rollback path, or “no rollback” if that is true
• invalidators: stale search result, changed label state, broad query, ambiguous user intent

That would let the connector unlock real inbox cleanup while still making the boundary visible: read-side classification can be automatic, but write-side label changes need a fresh, scoped confirmation receipt.