Multi-account email automation with Claude Code

I have three inboxes I check daily. My personal Gmail, my work Hostinger account, and a Proton inbox I use for things that ought to be encrypted. Switching between them used to be the friction in my morning routine: open three tabs, scan each, flag, file, draft, repeat.

What I wanted: one Claude Code session that knows about all three, can answer questions across them, and triages each according to rules that differ by account. Recruiter emails to work get a polite decline draft. Recruiter emails to personal get archived. Newsletters everywhere get summarized weekly.

This is what multi-account MCP email gets you. Here's how I set mine up and what works.

The naive setup that almost works

If you read the MCP spec carefully, you might assume you can run three separate MCP server instances, one per inbox, and add three entries to your .mcp.json. Like:

{
  "mcpServers": {
    "mcp-email-personal": { ... },
    "mcp-email-work": { ... },
    "mcp-email-proton": { ... }
  }
}

This works. Sort of.

The problems are subtle. Claude sees three identical tool surfaces (mcp-email-personal:list_messages, mcp-email-work:list_messages, and so on) and has to pick the right one for every call. The picking logic is "look at the conversation context and decide." It often gets it right. It also sometimes asks the user, or sometimes silently picks the wrong one and you don't notice until your work inbox has a draft addressed to your personal contact.

Three identical surfaces also blow up the tool list. Most MCP-using LLMs have a soft limit on how many tools they juggle before the picking gets fuzzy. Fifteen tools per server times three servers is 45 tools. Accuracy drops.

The better setup

What you want is one MCP server with multi-account routing built in. Every tool call takes an account argument:

mcp-email:list_messages(account="work", folder="INBOX", limit=20)
mcp-email:list_messages(account="personal", folder="INBOX", limit=20)
mcp-email:search_messages(account="proton", query="from:client@example.com")

Three account configs, one tool surface. Claude reasons about which inbox to read from in the same call it issues for the read itself. This eliminates the silent-mistake class of bugs.

mcp-email is built this way. Other MCP servers may or may not be — if you're shopping, check the API shape.

The config in practice

The .env for a three-account setup with mcp-email:

DEFAULT_DELIMITER=/

ACCOUNT_PERSONAL_EMAIL=me@gmail.com
ACCOUNT_PERSONAL_PASSWORD=...
ACCOUNT_PERSONAL_IMAP_HOST=imap.gmail.com
ACCOUNT_PERSONAL_IMAP_PORT=993
ACCOUNT_PERSONAL_SMTP_HOST=smtp.gmail.com
ACCOUNT_PERSONAL_SMTP_PORT=465

ACCOUNT_WORK_EMAIL=antoine@example.com
ACCOUNT_WORK_PASSWORD=...
ACCOUNT_WORK_IMAP_HOST=imap.hostinger.com
ACCOUNT_WORK_IMAP_PORT=993
ACCOUNT_WORK_SMTP_HOST=smtp.hostinger.com
ACCOUNT_WORK_SMTP_PORT=465

ACCOUNT_PROTON_EMAIL=me@proton.me
ACCOUNT_PROTON_PASSWORD=...
ACCOUNT_PROTON_IMAP_HOST=127.0.0.1
ACCOUNT_PROTON_IMAP_PORT=1143
ACCOUNT_PROTON_SMTP_HOST=127.0.0.1
ACCOUNT_PROTON_SMTP_PORT=1025

Each prefix becomes the account value Claude uses: personal, work, proton. There's no UI here, no extra config file, no separate server process. One .env, one server, Claude figures out the routing per call.

Workflow patterns that work

After a few months of running this daily, here are the patterns that have actually saved me time.

Pattern 1: morning triage across accounts

claude
"For each of personal, work, and proton, list unread messages from the last 24 hours.
Categorize as: recruiter, newsletter, client, personal, spam, action-required.
For action-required, summarize what's being asked in one sentence."

Output is a three-section markdown summary I can read in 30 seconds. Action items get my attention; the rest waits.

Pattern 2: cross-account search for a person

"Find every message from sarah@acme.com across all accounts in the last 90 days.
Build a timeline of the conversation."

Sarah might have emailed my personal address before we started working together, then switched to work once the contract was signed. Searching across accounts catches the full context. This used to require remembering which inbox to check.

Pattern 3: drafts that route correctly

"Reply to the latest message from a recruiter on work, polite decline, mention I'm at capacity until October. Save as draft."

Claude calls mcp-email:create_draft(account="work", ...). The draft shows up in my work Drafts folder. I review in the Hostinger webmail (or any IMAP client) before sending. The agent never has the ability to mis-route because the account argument is explicit.

Pattern 4: automated filing

"Any recruiter email older than 7 days that I haven't replied to: move to triage/recruiters on the right account. Mark read. Don't reply."

Folder structure matters here. I have triage/recruiters, triage/newsletters, triage/clients on each account, with consistent naming. The agent doesn't have to guess.

Privacy considerations

Running three accounts through one server means all three credentials are in one .env file. If that file leaks, all three accounts are compromised at once.

Mitigations I use:

The .env is chmod 600, owned by my user, lives on an encrypted disk volume
All three accounts use app passwords (not main account passwords), so revocation is instant if anything looks off
The MCP server runs as my user, not as root or a service account, so a process compromise doesn't escalate

For a personal setup this is enough. If you're doing this for a company inbox shared by a team, you'd want a different architecture: a service account, vault-backed credential injection, audit logging. But that's a different product.

A note on draft review

I don't let Claude auto-send anything. Every draft sits in the per-account Drafts folder until I review and send manually.

The temptation to enable auto-send goes up as you get used to the quality of the drafts. Resist it. The class of mistake you'll catch in review is exactly the class that's most embarrassing in production: wrong recipient, mis-routed account, accidental inclusion of context from another conversation. A 15-second review per draft is cheap. A "sent to all clients" bug is expensive.

create_draft instead of send is a workflow choice you make on day one. Make it deliberately.

Closing

If you only have one inbox, you don't need multi-account. If you have two, the naive setup will probably hold. If you have three or more, the explicit account argument is the difference between a system that mostly works and a system you trust.

mcp-email is distributed as a paid product. After checkout on https://shop.oneshotforge.com/l/mcp-email you get the full TypeScript source code, the Docker compose setup, the per-provider config docs, and a perpetual commercial license. The whole thing fits in a single zip. The README walks you through your first .mcp.json entry in Claude Code.