[FEATURE] Multi-account MCP connectors in Cowork (e.g., two Gmail accounts)

Feature Request

Is your feature request related to a problem?

Yes. In Cowork mode, each MCP connector (e.g., Gmail) can only be bound to a single account. For users who manage both personal and work email from the same machine — which is common for remote/hybrid workers — this means only one inbox is accessible via MCP tools.

My setup: I run Cowork from my home Mac Studio as a command center for both work and personal tasks. The Gmail MCP connector is bound to my personal account (eric@porres.com). My work account (eporres@logitech.com) has no MCP path, so I fall back to the Chrome browser extension to manually navigate and interact with my work Gmail.

This works, but it's significantly slower and more fragile than the MCP path — browser automation requires screenshots, scrolling, JavaScript DOM injection for composing replies, and manual checkbox selection for archiving. The MCP path handles all of that with clean API calls.

Describe the solution you'd like

Allow users to connect multiple instances of the same MCP connector, each bound to a different account. For example:

• Gmail (personal) → eric@porres.com
• Gmail (work) → eporres@logitech.com

Each instance would expose the same tools but scoped to its respective account. The user (or a skill) would specify which instance to use, either by name or by account identifier.

Possible implementation approaches:

1. Named connector instances — Allow users to add a connector multiple times with a user-defined label (e.g., "Gmail - Personal", "Gmail - Work"). Tools would be namespaced or the instance selected at invocation time.

1. Account switcher within a connector — A single Gmail connector that supports multiple authenticated accounts, with a parameter to select which account to query (similar to how Gmail itself supports multiple accounts in a single browser).

1. Connector profiles — A higher-level concept where users define "profiles" (e.g., "Work mode", "Personal mode") that bundle specific connector instances, and skills can request a profile context.

Describe alternatives you've considered

• Chrome browser extension fallback: This is what I currently do for work email. It works but is slower, more token-intensive, and requires workarounds for Gmail's DOM (e.g., createElement + insertBefore instead of innerHTML due to TrustedHTML CSP, and JavaScript injection instead of type actions because keystrokes land in the wrong field). I've documented these patterns in my email-triage skill, but they're inherently more brittle than MCP API calls.

• Separate Cowork sessions per account: Impractical — context and skills don't carry across sessions, and it defeats the purpose of having a single command center.

• Google Workspace delegation/forwarding: Doesn't solve the reply/archive use case since actions need to originate from the work account.

Additional context

This likely applies to any connector where users have multiple accounts: Google Calendar (personal + work), Slack (multiple workspaces), Google Drive, etc. The Gmail case is just the most immediately painful because email triage is a daily workflow.

I've built a dual-mode email triage skill that routes personal email through Gmail MCP and work email through Chrome browser automation. Happy to share the skill architecture if it's useful for thinking about the multi-account UX.

---
Filed from Cowork session • Claude Opus 4 • macOS (Mac Studio)