Google Workspace

Google Workspace MCP Server

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 ask in plain language"] agent["🤖 Your AI agent Claude Desktop, Claude Code…"] server["⚙️ This MCP server picks the right account, builds the real request"] keys[("🔑 Your accounts OAuth tokens, kept on your own machine")] google["☁️ Google Gmail · Calendar · Drive · Docs 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

• 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 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](docs/api-surface.md)

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 no