Support multiple Gmail accounts in MCP integration
Status Open
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 32 comments · opened Mar 19, 2026
Feature request
The Gmail MCP integration currently supports only one connected account at a time. Many users have multiple Gmail/Google Workspace accounts (personal + work) and would benefit from being able to connect more than one simultaneously.
Current behavior: Only one Gmail account can be connected via MCP. Connecting a second requires disconnecting the first.
Desired behavior: Ability to connect multiple Gmail accounts, with tools that can target a specific account (e.g., by email address).
Workaround: Using the Gmail API via custom CLI scripts for additional accounts, but this loses the native structured access that MCP provides.
32 Comments
Need this so much 🥺
yes please!
Amen!
Yes please
Need this so much as well (plus Calendar and Drive as well)
This is so needed!
+!
I desperately need this!
Need this its so annoying to have to switch the Gmail account connected multiple times per day to work on work and personal stuff.
Would be a game changer feature
Really need this.
yes
yes 100%
Please please please!!
Hitting this constantly. I run a personal Gmail and a business Gmail for my LLC. Most of my real workflows touch both inboxes (customer email on the business side, follow-ups and admin on the personal side). Having to disconnect and re-OAuth every time I switch is enough friction that I fall back to the Gmail web UI for anything cross-account, which defeats the point. Single-account binding is the bottleneck, not the tools themselves.
yep this is partially(majority) why I won't upgrade from Pro to Max.
yes please please please
Really need this.
Yes please
very desperate for this
+1 — daily friction for me. I run a personal and a business Google account and switch between them constantly, but the connector binds only one at a time, so every switch means disconnect/reconnect in Settings → Connectors. It hits Drive too, not just Gmail. Ideal: connect multiple Google accounts at once and pick which one a request targets (or get prompted when ambiguous).
I'm also hoping this will come one day. In the meantime I'm getting around it through a custom mcp that I host on my vps. I just uploaded the code in case it can help someone. https://github.com/devgar/gmail-mcp-proxy, it's a bit unstable, I'm having to reconfigure it in claude.ai every few days, but it's not too tedious.
P. S. With this I have solved my case, I am sure it would be possible to reimplement it for local, as a stdio server for Claude Code.
Please fix this! Need more than one.
When is this going to be implemented? It really is needed. Would like to manage both my personal and brand email accounts.
Yes please add support for 2 or more Gmail accounts!
Apparently it can be done via https://carlyassistant.com/ but Id much prefer native Anthropic support than an unknown 3rd party.
Thank you for creating and sharing this !! I forked it and spent much of today reviewing and modifying it.
Fixed a few issues, added some hardening, plus a couple of features. See changelog.md
Hosted via railway.com - and it seems to work well.
Claude Chat can now access my secondary Gmail account - and should be able to add several more if needed.
https://github.com/systmworks/gmail-mcp-proxy
@systmworks Very glad that it was useful to you, and thank you very much for the improvements, especially for the exploit fix.
I'm going to integrate that one right away and work on bringing me the rest of the improvements you've made.
Adding a data point beyond the personal-plus-work case.
I run three separate Google Workspace tenants: personal, my software company, and a real estate venture. They are legally and operationally distinct, so consolidation is not on the table and forwarding does not solve it, since replies and file writes have to originate from the correct identity.
Worth flagging that this is broader than Gmail. The connector authorizes one Google account, so connecting the company tenant also takes Drive and Calendar with it. Answering a question like "is the signed vendor agreement in any of my three Drives" means three disconnect and reconnect cycles, and by the third one the original context is gone.
The disconnect-reconnect loop is also more than an inconvenience for some of us. I have keratoconus, and every OAuth round trip is a real screen-time cost, not just a few extra clicks.
Approach 1 from the closed-as-duplicate #27567, named connector instances with user-defined labels, seems like the cleanest fit. Explicit labels such as "Gmail - Elevyr" and "Drive - Elevyr" would let a skill target an identity by name rather than inferring it, which matters when the wrong guess sends an email from the wrong company.
Happy to test if this ever reaches a preview.
You can do this today by running the Gmail MCP server twice with separate credential stores, one per account.
The server keeps its OAuth tokens in a config directory, so if you point each instance at a different directory, they stay independent. In your claude_desktop_config.json, define two entries with distinct names, something like this: 1. Add a "gmail-personal" server block with your normal command and args. 2. In its "env", set the credentials path variable the server uses, for the standard @gongrzhe/server-gmail-autoauth-mcp that's GMAIL_CREDENTIALS_PATH, plus GMAIL_OAUTH_PATH pointing at your OAuth client JSON. 3. Copy the block, rename it "gmail-work", and give it a different GMAIL_CREDENTIALS_PATH like ~/.gmail-mcp/work-credentials.json. 4. Run the auth flow once per instance from a terminal with that same env var set, signing into the matching account each time. 5. Restart Claude Desktop.
You'll then see two tool sets, prefixed by server name, so you target an account by picking gmail-work vs gmail-personal rather than by email address. Not as clean as a to parameter, but it's real native MCP access for both.
If your server build doesn't expose a credentials path variable, run each instance under a different HOME or use a wrapper script that sets it, same effect.
Full disclosure: I'm the developer of Multi Instance for Claude Desktop, which runs several isolated Claude Desktop instances at once, each with its own config and MCP servers, so you can keep work and personal Gmail fully separated in different windows.
https://apps.microsoft.com/detail/9NG247TJ47P0?cid=gh-multi
That only works on a local machine, not on iOS app or on Claude.ai
Thanks, I'm gonna check it out and give it a shot
+1 on this. I want to throw in a use case that I think is missing from the other reports, plus a note on how scattered this request has gotten.
It's not always work + personal
Most of the earlier reports frame this as "personal Gmail plus work Gmail." My situation is a third shape that I'd guess is pretty common for solo founders and small teams: I run two separate ventures, each with its own Google Workspace identity, plus a personal account. None of them is the main one. They're peers. So there's no sensible default to bind the connector to, because on any given day I'm bouncing between all three.
The current workaround (disconnect, re-auth, do the thing, disconnect, re-auth) costs maybe a minute each way. But the minute isn't really the problem. The problem is that anything spanning two identities, like "did the supplier reply on either address" or "pull every invoice from this month across both businesses," just can't be expressed at all. So I do it by hand, which is the thing I was trying to stop doing.
Scheduled tasks make it a lot worse
Worth calling out, since [#36829](https://github.com/anthropics/claude-code/issues/36829) got closed as not planned: single-account binding is mildly annoying in a normal chat, but it's close to a dealbreaker for scheduled or automated tasks. A recurring "summarize what came in overnight" is only worth having if it covers every inbox I actually get mail at. With one connector slot, an automation that quietly covers a third of my mail is arguably worse than no automation, because I'll end up trusting it.
What I'd want
Mostly echoing what's already in this thread, with one addition:
Gmail (business A),Gmail (business B),Gmail (personal). Each one holds its own OAuth grant.accountargument (the address, or the instance label). Leave it off and reads fan out across every connected account, while writes just error.The asymmetry in #2 is the important bit. Reading the wrong inbox is harmless. Replying from the wrong address is not. Making writes error unless you name an account avoids the bad half.
On the duplicates
This has been filed at least five times now:
The #30250 closure is the one that stands out, and I think it points at a process thing rather than an actual product decision. This is really a claude.ai / Cowork connector concern, but it keeps landing in the Claude Code repo because that's the tracker people can actually find. So each report gets closed as either a duplicate or out of scope, the signal splits five ways, and no single thread ever builds up enough weight to look like real demand.
If there's a better place to file claude.ai connector requests, it'd help a lot to have that written down somewhere findable. And ideally these would get consolidated into one canonical issue instead of closed off one at a time.