Google Multi-Account Connector

A remote MCP server that gives Claude access to several Google accounts at once — Gmail, Calendar, Drive, Contacts and Tasks. Claude's built-in Google connectors each hold exactly one account; connecting a second replaces the first. This holds as many as you link, and every search tool fans out across all of them in a single call.

You run it yourself. It holds your Google tokens in your own database, encrypted, and talks to Google directly — nothing passes through a third party.

Node and Postgres, four tables, and no dependencies beyond Express, pg and jsonwebtoken. Document text extraction — PDF, Word, Excel, PowerPoint, OpenDocument — uses only Node's standard library.

Status: running in production against real mailboxes, with 435 automated checks. Built for one person's needs and published because the one-account limit is not unique to them. Treat it as working software with a small user base, not as a hardened product.

Quick start

git clone https://github.com/ItsBreeze/google-multi-account-mcp.git
cd google-multi-account-mcp
npm install
cp .env.example .env      # fill it in — see Setup below
npm run migrate           # creates the four tables
npm start

Then deploy it somewhere with a public HTTPS URL (Railway, Fly, Render, a VPS — anything that runs Node and reaches Postgres) and follow Setup.

Endpoints

Tools (54)

Every tool takes an optional account. On a search, omitting it fans the call out across every linked account and merges the results — the thing no single-account connector can do. On a write it names the one account to act on, so "create this event" is never ambiguous about whose calendar it lands in.

Gmail (23)

Calendar (9)

Drive (15)

Contacts (2) and Tasks (5)

Document text extraction

read_file_content and get_attachment both return text for PDF, Word, Excel, PowerPoint and OpenDocument files, using only Node's standard library — no parsing dependency to vendor, audit or keep current.

Where it stops, and what happens then. Two kinds of PDF have no text to extract: a scan, which is a picture of a page, and one whose fonts are CID-keyed or subset, where the bytes in the content stream are glyph numbers that need the font's own tables to become letters. Both would decode into confident-looking nonsense, so the result is scored for readability and refused rather than returned — the refusal names the cause and points at the fix.

That fix is ocr: true on read_file_content, which copies the file as a Google Doc (Drive runs OCR during that conversion), exports the text, and deletes the copy in a finally block. It reads scans, photographs and images. Two things worth knowing: it is the one place this server writes to Drive during a read, and that delete is the only permanent delete in the whole server — its target is a file created seconds earlier by that same call, never anything the user put there. If the cleanup itself fails, the result says so and names the file.

Extraction is capped at 60 KB like every other body, with the cut flagged.

Shared drives

A shared drive is owned by an organisation rather than by a person, which is where a company's actual documents live. Drive's own default hides them: a files.list without corpora=allDrives searches only My Drive and files shared directly with the account, and a request naming a file inside a shared drive comes back 404 File not found unless it carries supportsAllDrives — an error that reads as a wrong id rather than as a missing capability.