google-workspace-mcp
An MCP server exposing Gmail, Calendar, Drive, Docs, Sheets, and Meet to AI agents — dual transport for Claude Code via stdio and LibreChat via HTTP/SSE.
highlights
- Full read/write coverage of Gmail, Calendar, Drive, Docs, Sheets, and Meet
- Dual transport — stdio for Claude Code/Desktop, HTTP/SSE with bearer-token auth for LibreChat
- Per-request credential injection over HTTP; no disk-stored OAuth tokens
- Built on Google's `gws` Rust CLI as the underlying API layer
Overview
Existing Google Workspace MCP options — including Google’s own official server — only expose partial read access. This fills that gap as part of a broader personal AI assistant setup: full read/write coverage across Gmail, Calendar, Drive, Docs, Sheets, and Meet, exposed as MCP tools to both Claude Code and LibreChat.
The server wraps Google’s gws Rust CLI (@googleworkspace/cli), which handles OAuth and the underlying API calls. The MCP layer curates which operations to expose and shapes responses for AI consumption rather than passing raw API output through.
Dual Transport
Two transports target two different clients:
- stdio — for Claude Code and Claude Desktop, spawned directly via
npx - HTTP/SSE — for LibreChat, running as a Docker container with bearer-token auth
The HTTP transport required a different credential model than stdio. Rather than OAuth tokens stored on disk (the local client approach), LibreChat injects credentials per-request via bearer token — the server validates those against the gws binary rather than managing its own OAuth state.
learnings
- Google's official MCP only covers partial read operations — wrapping the `gws` CLI was faster than reimplementing OAuth flows directly against each Workspace API
- stdio and HTTP transports need different credential models — disk-stored OAuth works for local clients, bearer-token per-request is the natural fit for a Docker-hosted server called by LibreChat