# google_workspace_mcp: A Google Workspace MCP Server for Claude, Cursor and Other AI Clients

> Taylor Wilsdon's server puts Gmail, Calendar, Drive, Docs, Sheets, Slides, Chat, Forms, Tasks, Contacts and Search behind 120+ MCP tools, with OAuth 2.1 multi-user auth and a stateless container mode. Here is how the setup works, where it stops, and who should pick something narrower.

**taylorwilsdon/google_workspace_mcp** — Control Gmail, Google Calendar, Docs, Sheets, Slides, Chat, Forms, Tasks, Search & Drive with AI - Comprehensive Google Workspace MCP Server & CLI Tool

- Repository: https://github.com/taylorwilsdon/google_workspace_mcp
- Website: https://workspacemcp.com
- Stars: 3,264 · Forks: 1,022
- Language: Python
- License: MIT
- Published: 2026-09-09 · Updated: 2026-09-09 · Language: en
- Canonical page: https://hysenlabs.com/projects/taylorwilsdon-google-workspace-mcp

## The gap google_workspace_mcp fills between a chat client and your Workspace account

A general AI assistant can read an email you paste into it. It cannot list tomorrow's calendar, find a Drive file by name, or append a row to a Sheet, because it has no authenticated path into those services. google_workspace_mcp is that path. It is a Python MCP server that exposes Google Workspace operations as tools an MCP client can call, so the model asks for "list my events tomorrow" and the server translates that into a Calendar API request made on behalf of the signed-in user.

The intended audience is developers and technically comfortable operators, not end users. You need a Google Cloud project, an OAuth client, and a client that speaks MCP. The README lists compatibility with Claude Desktop and Claude Code, ChatGPT Developer Mode, Cursor, and developer tooling generally. The project also ships a CLI and a "Code Mode" aimed at tools like Claude Code and Codex, so the same credentials can drive scripted work outside a chat window.

The scope claim is broad: twelve Workspace services, 120+ tools, one server. That breadth is the reason to consider it and also the reason to think carefully before enabling everything.

## One process, twelve service modules, three tool tiers

The repository layout is the clearest description of the architecture. Top-level directories map one-to-one onto services: gmail/, gcalendar/, gdrive/, gdocs/, gsheets/, gslides/, gchat/, gcontacts/, gforms/, gtasks/, gsearch/, with auth/ and core/ holding shared authentication and server plumbing. fastmcp_server.py and main.py are the entry points; fastmcp.json and server.json describe the server to MCP tooling.

Data flow is conventional for an MCP server. The client opens a session over stdio or streamable HTTP, the model selects a tool, the server validates arguments, resolves the authenticated user, calls the relevant Google API through google-api-python-client, and returns structured output. Credentials are handled by OAuth 2.1, and the docker-compose file shows the credential directory is a mounted volume (GOOGLE_MCP_CREDENTIALS_DIR=/app/store_creds), so tokens survive container restarts when a volume is attached.

The three progressive tool tiers are the design decision worth noticing. Rather than exposing all 120+ tools at once, the server lets you choose a tier, and the Dockerfile reflects this with TOOL_TIER and TOOLS environment variables that are appended to the startup command. A smaller tier means fewer tool definitions competing for the model's attention and fewer capabilities you have to review. There is also a read-only mode, which matters if you want an assistant that can look but not send, delete or share.

Stateless mode is the other structural choice. The README states it performs zero disk writes, which is what makes the server viable in locked-down container environments where the filesystem is read-only. The trade-off is implicit: anything that would normally persist to disk has to live elsewhere, which is why the deployment documentation covers external credential store backends such as GCS.

## Installing google_workspace_mcp and making the first tool call

Python 3.10 or newer is required. The package is published on PyPI as workspace-mcp, and the README points to the website quick start for the Google Cloud side, which is where the real work is: creating an OAuth client and downloading client_secret.json. None of that is avoidable, because the server uses your credentials against your GCP project.

The README does not give a standalone install command for a local stdio run, so the reliable path is the container. The compose file expects client_secret.json beside it and a named volume for stored credentials:

```yaml
services:
  gws_mcp:
    build: .
    container_name: gws_mcp
    ports:
      - "8000:8000"
    environment:
      - GOOGLE_MCP_CREDENTIALS_DIR=/app/store_creds
    volumes:
      - ./client_secret.json:/app/client_secret.json:ro
      - store_creds:/app/store_creds:rw
```

With docker compose up, the server listens on port 8000 and exposes a health endpoint the image's HEALTHCHECK polls. The image's own command runs the streamable HTTP transport, and its TOOL_TIER and TOOLS environment variables let you restrict what is loaded:

```dockerfile
ENV TOOL_TIER=""
ENV TOOLS=""
ENTRYPOINT ["/bin/sh", "-c"]
CMD ["uv run main.py --transport streamable-http ${TOOL_TIER:+--tool-tier \"$TOOL_TIER\"} ${TOOLS:+--tools $TOOLS}"]
```

Those two variables are empty by default, so an unmodified build starts with the server's default tool surface. Set them to the tier and tool names your deployment needs; the names come from the project's documentation, and an unrecognized value will leave you with a server that starts but exposes the wrong surface. Point your MCP client at the running server, and the first useful call is a read: ask it to list upcoming calendar events. A successful response confirms the OAuth token, the scope grant and the transport all work before you let it touch anything that sends mail or edits documents.

## Where the design pushes back: OAuth setup, file access and central hosting

The largest friction point is not the server, it is Google Cloud. You must create an OAuth client, register redirect URIs that match your deployment, and grant scopes. The README's FAQ and troubleshooting page is listed specifically for OAuth errors and redirect URI problems, which tells you these are common enough to warrant their own documentation. If your organization restricts OAuth client creation, this project is effectively unavailable to you regardless of how good the tool coverage is.

File access has deliberate limits. Local file reads default to a managed attachment directory, and validate_file_path() blocks .env* files plus common home-directory credential stores such as ~/.ssh/ and ~/.aws/, even when ALLOWED_FILE_DIRS is broadened. That is a sensible default, but it means workflows that expect the assistant to read an arbitrary path on the host will fail until you widen the allowed directories, and widening them re-opens the risk the blocklist exists to contain.

The breadth is a real cost. A server exposing 120+ tools across twelve services gives the model a large menu, and selecting the wrong tool or passing a malformed argument is a failure mode you will meet. The tool tiers and read-only mode are the mitigations the project offers, and using them is not optional if you care about blast radius. Multi-user and stateless deployment add another layer: the README advertises external auth server and gateway passthrough support, and the deployment docs cover reverse proxies, origin validation and credential store backends. That documentation exists because central hosting is genuinely more involved than a laptop install.

Finally, the project classifies itself as Beta in pyproject.toml, and releases arrive frequently (v1.25.1, v1.25.2 and v1.26.0 within a two-week window in late August and early September 2026). Fast iteration is good for coverage and less good for stability expectations. Pin a version in production.

## google_workspace_mcp vs a single-service Drive MCP server

The obvious alternative is a narrow MCP server that does one thing, most commonly Google Drive. A Drive-only server requests Drive scopes and nothing else, exposes a handful of tools, and has a much smaller review surface. If your workflow is "find this document and summarize it," that is the better fit, and it is also easier to get past a security review because the consent screen asks for less.

The difference is not just scope count, it is the shape of the work. A Drive-only server cannot read the email that references the document, cannot check the meeting where it was discussed, and cannot write a summary back into a Doc. google_workspace_mcp is built for the cross-service case: pull a thread from Gmail, attach the relevant file from Drive, put the result in a Doc, and post a note in Chat. That chain is where the twelve-service design earns its complexity.

The reverse trade-off is that the broad server is harder to reason about. With a narrow server you can enumerate every capability in a few minutes. Here, the tool tier you select effectively defines the product you are deploying, and the read-only flag defines whether it can change anything. Treat those two settings as the primary configuration decision, not an afterthought. Google's own built-in integrations with Claude and ChatGPT are another reference point, but the README's claim about them is a positioning statement rather than something this review can verify; what is verifiable from the repository is the tool count, the service directories and the auth modes.

## Licence, maintenance and the upgrade path

The project is MIT licensed, and the README is explicit that this is not open core, not source available, and not gated by a commercial tier or a contributor license agreement. For procurement, that means commercial use, forking, embedding and redistribution are permitted with attribution. The README also states there is no built-in telemetry: optional tracing is off unless you configure it, and the Dockerfile installs the OpenTelemetry extra in a way the comments describe as a no-op unless an OTLP endpoint is set. Dependency licences are described as MIT, Apache 2.0 and BSD throughout. This is a description of the project's own statements, not legal advice; check the LICENSE file and your dependency obligations yourself.

Maintenance is active by any reasonable reading. The last push was on 2026-09-08, and the most recent release, v1.26.0, was tagged on 2026-09-06. The repository is not archived. The cadence matters for upgrade cost: with releases landing every week or two, pinning matters more than usual. The Dockerfile installs with uv sync --frozen, which respects uv.lock, so a container build is reproducible until you deliberately update the lock file. For a pip or uvx install, pin the version explicitly rather than tracking latest, because a tool-surface change between minor versions can alter what your prompts do.

The upgrade cost you should budget for is not the code, it is the OAuth surface. If a release adds a service or expands scopes, users may need to re-consent, and centrally hosted deployments may need the GCP consent screen updated. Nothing in the README documents a rollback procedure, so plan your own by pinning versions and keeping the previous image tag.

## Conclusion

Adopt it if you want one MCP server covering most of Workspace, need multi-user OAuth, or intend to host it centrally for a team. Skip it if you only need Drive file reads, or if you cannot create a Google Cloud OAuth client. Before rollout, verify the redirect URIs registered in your GCP project match the ones your client uses, confirm which tool tier you want, and read the deployment docs on credential store backends and gateway identity.

## FAQ

### Does Google Workspace have an MCP?

Google does not ship one described in this repository. google_workspace_mcp is a third-party, MIT-licensed MCP server that connects AI clients to Google Workspace services using your own OAuth client credentials.

### Does Google have an MCP server?

The repository does not describe an official Google MCP server. It describes google_workspace_mcp, which the README positions as an alternative to Google's own tooling and the built-in Claude and ChatGPT integrations.

### Can I use Google Drive as an MCP server for Claude Code?

Yes, through google_workspace_mcp, which includes Drive alongside eleven other services and works with Claude Code. It also ships a CLI and Code Mode for use with tools like Claude Code and Codex.

### How do I install google_workspace_mcp?

It requires Python 3.10+ and is published on PyPI as workspace-mcp. The README points to the website quick start for Google Cloud setup, credentials and client connection; a Docker path is also provided via docker-compose.yml on port 8000.

### What is google_workspace_mcp?

It is an MCP server and CLI tool that gives AI assistants natural language control over Google Calendar, Drive, Gmail, Docs, Sheets, Slides, Forms, Tasks, Contacts and Chat, with OAuth 2.1 multi-user auth and a stateless deployment mode.

### Is there an MCP for Google Ads?

The repository does not cover Google Ads. The services listed are Calendar, Drive, Gmail, Docs, Sheets, Slides, Forms, Tasks, Contacts, Chat and Search.

## Sources

- [License: MIT](https://github.com/taylorwilsdon/google_workspace_mcp/blob/main/LICENSE)
- [Project website](https://workspacemcp.com)
- [README](https://github.com/taylorwilsdon/google_workspace_mcp/blob/main/README.md)
- [Releases](https://github.com/taylorwilsdon/google_workspace_mcp/releases)
- [taylorwilsdon/google_workspace_mcp on GitHub](https://github.com/taylorwilsdon/google_workspace_mcp)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/taylorwilsdon-google-workspace-mcp