Control Gmail, Google Calendar, Docs, Sheets, Slides, Chat, Forms, Tasks, Search & Drive with AI - Comprehensive Google Workspace MCP Server & CLI Tool
Copy the stdio config for Cursor, Claude Desktop, Claude Code, or VS Code on this page. It uses the publisher's install, not a PlugMCP proxy.
Does Google Workspace need an API key?
No required environment variable is listed on this record.
What transport does Google Workspace use?
Google Workspace runs locally over stdio.
When was Google Workspace last checked?
Last checked 2026-11-12. Control Gmail, Google Calendar, Docs, Sheets, Slides, Chat, Forms, Tasks, Search & Drive with AI - Comprehensive Google Workspace MCP Server & CLI Tool
<!-- mcp-name: io.github.taylorwilsdon/workspace-mcp -->
<div align="center">
# <span style="color:#cad8d9">Google Workspace MCP Server</span> <img src="https://github.com/user-attachments/assets/b89524e4-6e6e-49e6-ba77-00d6df0c6e5c" width="80"
From the publisher
Documentation
Google Workspace MCP Server
Full natural language control over Google Calendar, Drive, Gmail, Docs, Sheets, Slides, Forms, Tasks, Contacts, and Chat through all MCP clients, AI assistants and developer tools.Includes a full featured CLI & Code Mode for use with tools like Claude Code and Codex!
The most feature-complete Google Workspace MCP server is in a class of it's own: it can do things that Google's own tooling and the built in integrations with Claude and ChatGPT can't come close to with multi-user support, rich fine-grained editing tools and the most extensive coverage of any Workspace AI integration in existence.
By leveraging native OAuth 2.1, stateless deployment capability and external auth server & gateway passthrough auth support, it's also the only Workspace MCP you can host for your whole organization centrally & securely!
Supports all free Google accounts & Google Workspace plans with expanded app options like Chat & Spaces. Interested in a managed cloud instance? (starting at $5/mo).
Key features
01. Control Gmail, Google Calendar, Docs, Sheets, Slides, Chat, Forms, Tasks, Search & Drive with AI - Comprehensive Google Workspace MCP Server & CLI Tool
Workspace MCP connects AI assistants to all twelve major Google Workspace services - 120+ tools behind a single MCP server, with OAuth 2.1 multi-user auth, three progressive tool tiers, read-only mode, a full CLI, and stateless container deployment. It runs locally over stdio for legacy clients and remotely over streamable HTTP with full implementation of the latest MCP spec.
The README covers just enough to get you running, with extensive documentation on the website:
Enabling Google APIs, OAuth errors, redirect URIs, Google Chat setup, client quirks
Security & Compliance
For Security Teams
By default, this server sends no data anywhere except Google's APIs, on behalf of the authenticated user, using your own OAuth client credentials. There is no usage reporting, analytics, license server, or SaaS dependency outside optional OTel support for your own usage.
Fully open source — every line is auditable in this repo
Your OAuth client, your GCP project — credentials never leave your environment & you control scopes
You control the network — deploy behind your reverse proxy, in your VPC, on your own terms
Stateless mode — zero disk writes for locked-down container environments
Sensitive path blocking — local file reads default to the managed attachment directory, and validate_file_path() still blocks .env* files plus common home-directory credential stores such as ~/.ssh/ and ~/.aws/ even if ALLOWED_FILE_DIRS is broadened
Full dependency tree in pyproject.toml, pinned in uv.lock.
Use commercially without restriction — build products, sell services, deploy internally
Fork, embed, redistribute — MIT requires only attribution
No CLA — contributions remain under MIT
No built-in telemetry to disclose — optional tracing is off unless you configure it
No network effects — the server never contacts any endpoint you didn't configure
Standard dependency licenses — MIT, Apache 2.0, and BSD throughout the dependency chain; no copyleft, no AGPL
Services
Each page lists every tool with its tier, parameters, required scopes, and example prompts. The complete reference covers all twelve in one place.
💬 Google Chat needs a one-time Chat app configuration and a Workspace account - see the Chat setup FAQ.
Quick Start
Set credentials → pick a launch command → connect your client. Full walkthrough with screenshots: workspacemcp.com/quick-start
You'll need an OAuth client from Google Cloud Console in a project with the Google APIs enabled for the services you plan to use. The docs have one-click enable links for every API plus a single gcloud services enable command that covers them all, and the quick start guide walks through the whole setup in about five minutes.
# 1. Credentials - MCP clients connect with PKCE and no
# secret, but Google still requires one server-side
export MCP_ENABLE_OAUTH21=true
export GOOGLE_OAUTH_CLIENT_ID="..."
export GOOGLE_OAUTH_CLIENT_SECRET="..."
# Alternatively, point GOOGLE_CLIENT_SECRET_PATH at a client_secret.json
# that contains the client id and secret (env vars take precedence).
export WORKSPACE_MCP_PORT=8000
export GOOGLE_OAUTH_REDIRECT_URI="http://localhost:${WORKSPACE_MCP_PORT}/oauth2callback"
export OAUTHLIB_INSECURE_TRANSPORT=1
# 2. Launch - OAuth 2.1 requires HTTP transport
uvx workspace-mcp --transport streamable-http --tool-tier core
Tool tiers keep context windows lean: core is the essential set, extended adds management operations, complete loads everything. Combine with --tools <service> ..., --read-only, or per-service --permissions, and subtract individual tools with --disabled-tools <name> ... - details in the server modes docs.
Connect Your Client
Claude Desktop, web & mobile - run the server in HTTP mode and add it as a Connector (Settings → Connectors → Add custom connector). This is the recommended path; the Connector guide has step-by-step screenshots. Legacy stdio configuration remains available for clients without Connector support - see the FAQ.
Claude Code
# Start the server in HTTP mode, then:
claude mcp add --transport http workspace-mcp http://localhost:8000/mcp
# Optional: install the bundled skill for better Workspace tool routing
ln -s "$(pwd)/skills/managing-google-workspace" ~/.claude/skills/managing-google-workspace
ChatGPT - connect via Developer Mode with the ChatGPT guide.
VS Code, LM Studio, Open WebUI, and everything else - any MCP client works over streamable HTTP (recommended) or stdio. Client-specific walkthroughs live in the guides and FAQ.
CLI
workspace-cli lists and calls tools against a running server with encrypted, disk-backed OAuth token caching - authenticate once, script forever:
uv run workspace-cli list
uv run workspace-cli call search_gmail_messages query="is:unread" max_results=5
Install globally with uv tool install . from this repo. ⚠️ Don't use uvx workspace-cli - an abandoned PyPI package squats that name.
Deployment & Advanced Configuration
Everything you need to run this in production lives in two places. The documentation covers auth modes and server configuration:
The Advanced Deployment guide covers self-hosting specifics: reverse proxy setup with WORKSPACE_EXTERNAL_URL (including the nginx Origin: null consent workaround, the WORKSPACE_MCP_ALLOW_NULL_ORIGIN_CONSENT escape hatch, and the Referrer-Policy pitfall), origin validation and VS Code webview allowlisting, credential store backends (local directory or GCS with CMEK enforcement), and the complete environment variable reference.
Production tuning is all environment variables; the names below link to their reference entries.
Hosted servers without access to the caller's disk:WORKSPACE_MCP_DISABLE_LOCAL_FILES
With local files disabled, create_drive_file, update_drive_file and the import tools offer return_upload_url: the caller PUTs the bytes to the returned URL. If the file sits in a cloud-mirrored folder (Drive for desktop), copy it to a local directory first, since mirrored paths can stall mid-upload.
OAuth 2.1 token refresh and lifetimes: see .env.oauth21
For downloads, horizontally scaled or scale-to-zero HTTP deployments (Cloud Run, Kubernetes) can stage attachments in Google Cloud Storage instead of instance-local disk, whose /attachments/{id} URL may reach a different instance. Install the gcs extra and set WORKSPACE_MCP_FILES_GCS_BUCKET to a bucket name; objects are written under WORKSPACE_MCP_FILES_GCS_PREFIX (default attachments) and handed out as V4 signed URLs valid for one hour, which the client fetches straight from GCS. This also lets stateless mode return download URLs instead of inline files. stdio ignores the setting, since its client reads the local file path directly. The runtime service account needs object read and write access on the bucket — roles/storage.objectUser, or roles/storage.objectCreator plus roles/storage.objectViewer — and, without an exported private key, roles/iam.serviceAccountTokenCreator on itself so URLs can be signed through IAM. Read access is not optional: a signed URL carries the signer's authority, so without storage.objects.get the upload and the signing both succeed while the client's download fails with 403. Objects are not deleted by the server, so add a bucket lifecycle rule that removes them after a few hours.
Security Best Practices
By default this server sends no data anywhere except Google's APIs, using your own OAuth client credentials - no usage reporting, analytics, license server, or SaaS dependency. MIT licensed with no CLA, no dual licensing, and no copyleft in the dependency chain. The full security posture - scope minimization, sensitive-path blocking, stateless mode - is documented at workspacemcp.com.
A few things worth internalizing before you connect an LLM to your email:
Prompt injection is real. Emails, docs, and events can contain hidden instructions. Only connect trusted data to an LLM, and be deliberate about which write tools you enable.
Never commit.env, client_secret.json, or .credentials/ to source control.
Local file reads are sandboxed to the managed attachment directory. Broaden with ALLOWED_FILE_DIRS only if you trust the client and its data sources; .env*, ~/.ssh/, ~/.aws/, and similar paths are always blocked.
Production deployments should use HTTPS and OAuth 2.1.
Development
uv sync --group dev # install deps
uv run ruff check . # lint
uv run pytest # test
Single-file service modules live in g<service>/, tools are registered with @server.tool decorators, and tiers are defined in core/tool_tiers.yaml. PRs welcome.
License
MIT - see LICENSE. The license is 21 lines and says what it means.
