Google Workspace

Google Workspace MCP Server

[npm version] [Latest release] [Node] [License]

Give your AI agent real access to Google Workspace — Gmail, Calendar, Drive, Docs, Sheets, Tasks, Meet and Contacts — from one MCP server, across as many accounts as you have.

Search your mail, check your calendar, write a doc, file a task — in conversation, as yourself.

Install

First, you need Google OAuth credentials — the one prerequisite common to every path:

1. Go to console.cloud.google.com/apis/credentials
2. Create an OAuth 2.0 Client ID, application type Desktop app
3. Enable the APIs you want (Gmail, Calendar, Drive, Sheets, Docs, Tasks, Meet — and People API for contacts, which is what Google calls it in the console)
4. Keep the Client ID and Client Secret handy — you'll paste them in below

Then pick the path that matches how you work. All three run the same server.

Node 22.12 or newer. (Node 18 and 20 are both end-of-life.)

📦 → 🤖 Claude Desktop — one-click .mcpb install (recommended)

Download google-workspace-mcp.mcpb from the latest release, then drag it onto the Claude Desktop window, or double-click it.

Claude Desktop opens an install dialog with three fields:

Paste, hit Save, done. No JSON to edit, no Node to install, no paths to get right — the bundle carries the server and every dependency.

One bundle covers every platform — macOS (Intel and Apple Silicon), Linux (x64 and ARM64), and Windows. There is nothing to choose: the server is pure JavaScript, so there is no platform-specific payload to pick between.

Cross-platform note: .mcpb files install via Claude Desktop's bundled handler. If double-clicking doesn't trigger Claude on your system, drag the file onto the Claude Desktop window instead, or right-click → "Open with…" and pick Claude Desktop (then "always open with" if your OS offers). Behavior varies: macOS usually auto-associates, Windows may need a one-time association, Linux varies by desktop environment.

Claude Code — one command

claude mcp add google-workspace \  -e GOOGLE_CLIENT_ID=your-client-id \  -e GOOGLE_CLIENT_SECRET=your-client-secret \  -- npx -y @aaronsb/google-workspace-mcp

That's it — no file to edit. Verify with /mcp.

Other MCP clients

Add an entry to the client's MCP config file (for Claude Desktop by hand, that's claude_desktop_config.json; for Claude Code, .mcp.json):

{  "mcpServers": {    "google-workspace": {      "command": "npx",      "args": ["-y", "@aaronsb/google-workspace-mcp"],      "env": {        "GOOGLE_CLIENT_ID": "your-client-id",        "GOOGLE_CLIENT_SECRET": "your-client-secret"      }    }  }}

Or install it globally and point at the binary directly:

npm install -g @aaronsb/google-workspace-mcp

How it fits together

flowchart LR    human["🧑 You<br>ask in plain language"]    agent["🤖 Your AI agent<br>Claude Desktop, Claude Code…"]    server["⚙️ This MCP server<br>picks the right account,<br>builds the real request"]    keys[("🔑 Your accounts<br>OAuth tokens, kept<br>on your own machine")]    google["☁️ Google<br>Gmail · Calendar · Drive · Docs<br>Sheets · Tasks · Meet · Contacts"]
    human -->|"“what's on my calendar?”"| agent    agent -->|"tool call"| server    server <-->|"which account?"| keys    server -->|"real API call, as you"| google    google -->|"your data"| server    server -->|"shaped for an agent<br>+ what to do next"| agent    agent -->|"an answer"| human
    classDef person   fill:#475569,color:#ffffff,stroke:#94a3b8    classDef robot    fill:#2d7d9a,color:#ffffff,stroke:#4a5568    classDef ours     fill:#7c3aed,color:#ffffff,stroke:#8b5cf6    classDef secrets  fill:#2d8e5e,color:#ffffff,stroke:#4a5568    classDef external fill:#f6821f,color:#1a1a1a,stroke:#d97706
    class human person    class agent robot    class server ours    class keys secrets    class google external

Your credentials never leave your machine. The server holds an OAuth token per account, on your own disk, and calls Google as you — there is no middleman service, no account of ours, nothing to sign up for. Add as many accounts as you like (personal and work, side by side); the server routes each request to the right one.

What it can do

12 tools across 8 Google services, plus multi-account handling, per-account read-only access, bulk execution, content authoring, and a file sandbox.

Every response carries next-steps guidance, so the agent always knows what it can do next.

One ask, many steps

The useful part isn't any single operation — it's that your agent can string them together.

You ask for one thing. The agent works out that it needs four API calls, in order, each one feeding the next:

sequenceDiagram    autonumber    participant H as 🧑 You    participant A as 🤖 Your agent    participant S as ⚙️ MCP server    participant G as ☁️ Google
    H->>A: "file the invoice from Acme<br>and remind me to pay it Friday"    A->>S: find the email    S->>G: search Gmail    G-->>S: the message    S-->>A: found it — and here's what you can do next    A->>S: save the attachment    S->>G: download it    A->>S: put it in Drive    S->>G: upload    A->>S: create a task, due Friday    S->>G: Google Tasks    A-->>H: Done. Invoice filed, task set for Friday.

Two things make this work. Every response tells the agent what it can do next, so it isn't guessing at the next step. And bulk_operations lets it run a whole chain in one call, feeding each result into the next — so "find the invoice, file it, remind me" is a single round trip rather than four.

When the work is the same operation over many things, it can go further and use one Google request for all of them:

bulk_operations { mode: 'batch', tool: 'manage_email', operation: 'trash',                  items: ['msg1', 'msg2', 'msg3', … ] }

Two hundred messages trashed in one round trip instead of two hundred. This is narrow on purpose — it works only where Google publishes a method for it, which today is contacts (create, update, delete, get) and Gmail (trash, label changes). Ask for it anywhere else and the answer names the operations that can, and points you back at sequential mode, which works everywhere.

Ask for what's missing

This server exposes 95 operations, reaching 79 of the 257 methods Google publishes across those eight APIs. It is a curated subset on purpose: an agent has to choose among these, and every method it must weigh is one it can pick wrongly. A tool with 257 operations isn't more capable than one with 95 — it's harder to use correctly.

But that judgement was made without you.

→ Browse every method Google publishes

Every method is listed — what it does, whether we expose it, and a Request link that opens a pre-filled issue. The descriptions are Google's own, quoted verbatim, and the page is generated from the same specification the client is built from, so it can't drift from reality.

That page also lists three whole APIs this server doesn't touch yet — Chat, Slides and Forms — for the same reason: not targeted is a decision, not a fact of nature.

A good request names the task, not the method:

"I want the agent to file incoming invoices into a folder automatically."

That can be evaluated. It might turn out an existing operation already does it, or that the right answer is a different method than the one you found. "Expose users.settings.filters.create" is a conclusion, not a case — lead with the problem and let the method follow.

Why Apache 2.0, and not open core

Everything is here. There is no paid tier, no "enterprise" build, no feature held back to sell you later. What you install is what exists.

Open core works by keeping the good part back. The free thing is a lead magnet, and the moment your use gets serious you discover the operation you need lives behind a licence. That model would be especially rotten here: this is a piece of plumbing between you and your own data, using your own Google credentials, running on your own machine. Nothing about that arrangement should have a paywall in the middle of it, and nothing about it needs a vendor.

Apache 2.0 rather than MIT for two concrete reasons:

• An explicit patent grant. Contributors licence their patent claims along with their code, so using this can't become a patent problem later. MIT is silent on patents, which means the question is merely unanswered rather than settled.
• It's safe to adopt at work. Apache 2.0 is on essentially every corporate allow-list. Fork it, vendor it, ship it inside a commercial product — you don't owe anyone anything, and you don't need to ask.

The one obligation is attribution: keep the notices (NOTICE, LICENSE) with the code. That's it.

Through v3.0.0 this project was MIT-licensed, and that history is preserved rather than erased — MIT-era contributions keep their original notice in LICENSE-MIT, and their authors are credited in NOTICE. Apache 2.0 takes back nothing MIT permitted.

Usage

Add an account (opens a browser for OAuth):

manage_accounts { "operation": "authenticate" }

Then use any tool with your account email:

manage_email    { "operation": "triage", "email": "[email protected]" }manage_calendar { "operation": "agenda", "email": "[email protected]" }manage_drive    { "operation": "search", "email": "[email protected]", "query": "quarterly report" }

Give an account read-only access

Some accounts should never be written to. Ask for less at consent time and the token itself cannot send, edit or delete — this isn't a rule layered over a broad token:

manage_accounts { "operation": "scopes", "email": "[email protected]",                  "services": "gmail,drive,contacts", "access": "read" }

Google is asked for the read-only variant of each scope, so ticking every box on the consent screen still yields a read-only token. manage_accounts status reports what each account actually holds.

A write from a read-only account is refused before the request leaves, with the account, the operation, and the way back:

'create' needs write access to contacts. Account [email protected] was authorizedread-only for contacts. Re-authorize with manage_accounts {operation:'scopes',email:'[email protected]', services:'contacts', access:'readwrite'}, or use anaccount that already has it.

Where a service has no read-only scope, you're told which ones and what they'll still be able to do before the browser opens.

Multi-step workflows

Chain operations with result references — the output of one step feeds the next:

{  "operations": [    { "tool": "manage_email", "args": { "operation": "search", "email": "[email protected]", "query": "from:boss subject:review" }},    { "tool": "manage_email", "args": { "operation": "read", "email": "[email protected]", "messageId": "$0.messageId" }}  ]}

One operation, many things

Where Google publishes a method for it, the same operation across many resources costs one request:

{  "mode": "batch",  "tool": "manage_contacts",  "operation": "delete",  "email": "[email protected]",  "items": ["people/c1", "people/c2", "people/c3"]}

Anything shared by the whole batch goes at the top level; items carry only what differs — a bare id is enough when that's all it is.

Where your data lives

Follows the XDG Base Directory Specification:

Credentials are per-account files holding standard OAuth tokens. No secrets are stored in the project directory.

Under the hood

You don't need any of this to use the server. But if you're curious, or you want to add an operation:

The server builds its Google API client from Google's own machine-readable API specifications. Nothing is transcribed by hand, so the surface can't drift from reality, and adding an operation is a YAML edit rather than a code change.

• How it works — the build-time / runtime split, the descriptor, the factory
• API coverage — what's exposed, what isn't, and how to ask for more
• The full API surface — every method Google publishes, plus the three APIs we don't target yet
• Architecture decisions — the ADRs, including why this server owns its Google client outright

License

Apache License 2.0 — see Why Apache 2.0 above.