The purpose of the Google Workspace MCP Server is to let AI assistants, MCP clients, and developer tools control Google Workspace services through natural language. It connects all twelve major Workspace services, provides more than 120 tools behind a single MCP server, and comes with a fully featured CLI and Code Mode, which can be used for tools such as Claude Code and Codex.
In terms of main capabilities, the project covers Google Calendar, Drive, Gmail, Docs, Sheets, Slides, Forms, Tasks, Contacts, and Chat, among others, and supports multi-user, fine-grained editing tools. It provides a three-level progressive tool hierarchy: core is the core feature set, extended adds administrative operations, and complete loads all tools, in order to control context window usage. It also supports --tools <service>, --read-only, per-service --permissions, and subtracting individual tools via --disabled-tools <name>. For authentication, it uses native OAuth 2.1, supports stateless deployment, external authentication servers, and gateway pass-through authentication, and can be centrally and securely hosted for an entire organization. It supports all free Google accounts and Google Workspace plans, and provides extended application options such as Chat and Spaces. The project also offers a hosted cloud instance option, starting at $5 per month.
In terms of usage, the basic process is: set up credentials → choose a startup command → connect a client. You first need to create an OAuth client in the Google Cloud Console and enable the Google APIs corresponding to the services you plan to use in the project; the documentation provides one-click enable links for each API as well as a gcloud services enable command covering all APIs, and the quick start guide can complete setup in about five minutes. Client connection methods include: Claude Desktop, web version, and mobile version; it is recommended to run the server in HTTP mode and add it as a Connector (Settings → Connectors → Add custom connector); the legacy stdio configuration can still be used for clients that do not support Connectors. ChatGPT can connect through Developer Mode. VS Code, LM Studio, Open WebUI, and any other MCP client can connect via streamable HTTP (recommended) or stdio. The CLI tool workspace-cli lists and invokes tools for a running server, with encrypted, disk-backed OAuth token caching, so one authentication is enough for long-term scripted use; it must be installed globally from this repository with uv tool install ., and note that uvx workspace-cli should not be used, because that name is occupied by a deprecated PyPI package.
In terms of deployment and advanced configuration, the documentation covers OAuth 2.1 multi-user authentication (bearer token required for remote or shared HTTP endpoints), stateless container mode (zero disk writes), OAuth proxy storage backends (memory, disk, or Valkey/Redis for distributed deployments), external OAuth provider mode, service account with domain-wide delegation, trusted gateway identity (Pomerium, Cloudflare Access, oauth2-proxy, or any gateway that can verify JWKS), and optional OpenTelemetry tracing (disabled by default). The Docker method is docker build -t workspace-mcp . && docker run -p 8000:8000 workspace-mcp. Production tuning is done through environment variables, such as WORKSPACE_MCP_GOOGLE_API_WORKERS and WORKSPACE_MCP_GOOGLE_API_TIMEOUT_SECONDS for Google API requests, WORKSPACE_MCP_TOKEN_VALIDATION_WORKERS and WORKSPACE_MCP_TOKEN_VALIDATION_CACHE_TTL for external OAuth token validation, and WORKSPACE_MCP_MAX_FILE_BYTES, WORKSPACE_MCP_STATELESS_INLINE_MAX_BYTES, and WORKSPACE_MCP_MAX_OFFICE_XML_BYTES for memory limits,WORKSPACE_MCP_SESSION_IDLE_TIMEOUT for sessions and health probes, WORKSPACE_MCP_READINESS_TIMEOUT_SECONDS, and WORKSPACE_MCP_DISABLE_LOCAL_FILES for managed servers that do not have caller disk access. For HTTP deployments that involve downloads, horizontal scaling, or scaling to zero (Cloud Run, Kubernetes), you can install the gcs extra and set WORKSPACE_MCP_FILES_GCS_BUCKET; attachments will be staged to Google Cloud Storage, objects will be written under WORKSPACE_MCP_FILES_GCS_PREFIX (default attachments), and served via V4 signed URLs valid for one hour.
Applicable scenarios include: individual users managing email, calendars, documents, spreadsheets, etc. with AI; teams or organizations centrally hosting Workspace AI integrations; developers building related automation or integration products; and deployment in production environments that require multi-user, fine-grained permission control.
Regarding limitations and caveats, Google Chat requires one-time configuration of the Chat app and requires a Workspace account. By default, the server only sends data to Google APIs on behalf of the authenticated user and does not use any reporting, analytics, licensing server, or SaaS dependency other than its own OAuth client credentials; optional tracing is disabled by default. The project uses the MIT license, with no CLA, no dual licensing, and no copyleft. On security, the risk of prompt injection is real; emails, documents, and events may contain hidden instructions, so you should connect only trusted data and enable write tools with caution. Never commit .env, client_secret.json, or .credentials/ to source control. Local file reads are sandboxed by default in the managed attachments directory; even if ALLOWED_FILE_DIRS is broadened, sensitive paths such as .env*, ~/.ssh/, ~/.aws/, etc. are always blocked. Production deployments should use HTTPS and OAuth 2.1. For a more complete reference on domains, the specific API list, individual tool parameters and scopes, etc., the materials do not list them one by one; see the project documentation.