Gws MCP Server

gws-mcp-server

Maintenance mode. This project is stable and receives security fixes. New features aren't planned, but issues and pull requests are still welcome.

Google Workspace for AI agents: Gmail, Calendar, Drive, Sheets, Docs, Slides, Tasks, and Contacts as a curated set of 67 Model Context Protocol tools, built on the official Google Workspace CLI (gws).

Why?

The gws CLI had a built-in MCP server that was removed in v0.8.0 because it exposed 200-400 tools — causing context window bloat in MCP clients. This server takes a curated approach: you choose which Google services to expose, and only a focused set of high-value, narrowly scoped operations are registered as tools. Every tool declares all four MCP annotation hints — readOnlyHint, destructiveHint, idempotentHint, openWorldHint — so clients can reason about side effects, know which writes are safe to retry, and surface clearer consent prompts. This is the permissions leg of trust infrastructure for agents: a deliberately narrow tool surface, side effects declared on every tool, and no freestanding send tool — the only outbound email an agent can trigger is calendar invite/update notifications, opt-in via sendUpdates and off by default.

Prerequisites

• Node.js 18+
• gws CLI installed and authenticated (npm install -g @googleworkspace/cli && gws auth login)

Grant fewer scopes than the default

This server exposes no freestanding send tool — gmail_drafts_create explicitly does not send, and the only outbound email an agent can trigger is calendar invite/update notifications via sendUpdates, which is enum-validated and defaults to none. The token gws auth login mints is broader than that.

gws auth login opens a scope picker listing nine scopes. The default grant is seven: full read-write drive, spreadsheets, gmail.modify (Google documents it as "Read, compose, and send emails"), calendar, documents, presentations, and tasks — the same seven you get running non-interactively as DEFAULT_SCOPES.

The other two rows are Cloud Pub/Sub and Cloud Platform, and neither is part of the default grant — gws auth login --help describes --full as "Request all scopes incl. pubsub + cloud-platform."

Which rows start checked has not been verified against a live picker — the seven above are the documented default grant, not an observation of the TUI. Read the checkboxes before pressing Enter rather than trusting this paragraph.

So the token on disk can send mail and rewrite Drive even though nothing here will. Deselect what you do not need in the picker, or:

gws auth login --readonly    # read-only across services

-s gmail limits the picker to Gmail, per the flag's own help text ("Comma-separated service names to limit scope picker"). It cannot pull in cloud-platform or pubsub, because those two are reachable only through --full. It also replaces any credential you already have rather than adding to it. To add a service to an existing login, use gws-mcp-server auth login.

On Linux there is no keyring, and the encryption key is a file next to the data it encrypts. gws enables the keyring crate's native backends only for macOS and Windows; on every other platform the dependency is declared with no backend feature, so the store falls through to writing .encryption_key into ~/.config/gws/. That file is not a backup of a key held elsewhere — it is the key, and the credential store's own doc comment says it is never deleted. Setting GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file changes nothing there because that is already the only path. On macOS and Windows the key file is removed once the OS keyring holds the key. If you run this headless on Linux, treat ~/.config/gws/ as a password file: anyone who can read the directory has the credentials.

Contacts needs a scope outside the default grant

The people_* tools need the contacts scope, which the default gws auth login (and the seven-scope grant described above) does not request.

Add Contacts with gws-mcp-server auth login -s people, not gws auth login -s people. gws's own filtered login replaces the saved credential with only the filtered scopes, so it drops Drive, Gmail, Calendar and everything else you had granted (#68, tracked upstream in googleworkspace/cli#673). This server's auth login does incremental authorization instead:

gws-mcp-server auth login -s people              # keep existing scopes, add contacts
gws-mcp-server auth login -s people --dry-run    # print the gws command first

It reads the scopes the saved credential holds from gws auth status, adds the requested services' scopes, and runs gws auth login --scopes <existing + new>. You consent once in the browser, and afterwards it re-reads gws auth status and exits non-zero if any scope you asked for (old or new) wasn't granted, for example because a box was unticked on Google's consent screen. gws saves whatever the consent screen granted, so an unticked box does remove that scope from the saved credential. Before the browser opens, and again if anything is missing afterwards, the command prints the gws auth login --scopes "..." command that re-requests the complete list. It needs a client configured for gws auth login already, and it exits without changing anything if the credential already covers the services.

gws auth status discovers scopes live (refresh-token exchange plus Google's token-info lookup), so the scopes field can be missing when that fails. When a saved credential exists but its scopes can't be read, auth login refuses rather than guessing; fix the status lookup and retry. If you really mean to start over with only the requested scopes, pass --replace. With no saved credential at all it is a first login and requests just the services you name.

If you prefer to run gws directly, pass the complete list yourself. For a credential that used exactly the default seven scopes described above:

gws auth login --scopes "https://www.googleapis.com/auth/drive,https://www.googleapis.com/auth/spreadsheets,https://www.googleapis.com/auth/gmail.modify,https://www.googleapis.com/auth/calendar,https://www.googleapis.com/auth/documents,https://www.googleapis.com/auth/presentations,https://www.googleapis.com/auth/tasks,https://www.googleapis.com/auth/contacts"

The People API must also be enabled on your own GCP project — a one-time step separate from OAuth, since a new scope grant doesn't enable a new API by itself:

gcloud services enable people.googleapis.com --project=<your-project-id>

Without both steps, people_* tools fail: a missing scope surfaces as a 401/403 from Google, and a disabled API surfaces as a distinct 403 naming the API and a console link to enable it.

Quick start

# Install
npm install -g gws-mcp-server

# Or run from source
git clone https://github.com/conorbronsdon/gws-mcp-server.git
cd gws-mcp-server
npm install && npm run build

Configuration

Claude Code (.mcp.json)

{
  "mcpServers": {
    "google-workspace": {
      "command": "npx",
      "args": [
        "gws-mcp-server",
        "--services", "drive,sheets,calendar,docs,slides,gmail,tasks"
      ]
    }
  }
}

Contacts is opt-in because it needs additional authentication and API setup. After completing the Contacts prerequisites, append people to the service list:

"args": ["gws-mcp-server", "--services", "drive,calendar,people"]

Claude Desktop (claude_desktop_config.json)

{
  "mcpServers": {
    "google-workspace": {
      "command": "npx",
      "args": [
        "gws-mcp-server",
        "--services", "drive,sheets,calendar"
      ]
    }
  }
}

Options

On Windows, npm's gws.cmd is resolved to its JavaScript entry point and run with Node. --gws-path or GWS_BINARY may also point directly to a JavaScript entry point or .exe.