Google Workspace MCP and Gmail MCP: What Actually Touches Your Inbox

Gmail, Calendar and Drive are the highest-signal data an agent can read, and the highest-risk. Signal, because a mailbox is the one place that already knows who you work with, what they want from you and when it is due. Risk, because every tool that reads it can usually write to it too, and a mailbox is also the place password resets land.

Google Workspace MCP is not one thing. It is a set of MCP servers, official and open-source, with different auth models, different tool lists and different blast radii. Before you point one at a mailbox, know exactly which tools it exposes and who holds the token.

What Google Workspace MCP actually covers

Two different things answer to “Google Workspace MCP,” and conflating them is the first mistake. Gmail-only servers are a third category, covered below.

Google ships its own remote MCP servers, one per product: Gmail, Drive, Docs, Sheets, Slides, Calendar, Chat and the People API, each at its own hosted endpoint (gmailmcp.googleapis.com, drivemcp.googleapis.com, and so on). You do not run these. Google does, and your MCP client authenticates to them with OAuth 2.0 through an OAuth client you create in your own Google Cloud project. They require enabling both the product API (gmail.googleapis.com) and a second, MCP-specific API (gmailmcp.googleapis.com) per Google’s own setup guide.

Then there is the open-source middle ground: taylorwilsdon/google_workspace_mcp, MIT-licensed, 3,268 GitHub stars as of this check. One server, twelve services (Gmail, Drive, Calendar, Docs, Sheets, Slides, Forms, Tasks, Contacts, Chat, Custom Search and Apps Script), over 120 tools behind it. You self-host it, point it at your own OAuth client, and it supports both a single-user “confidential client” mode and full OAuth 2.1 with PKCE for multiple users behind one deployment.

Two ways to get Workspace into an agent

Both put Google's OAuth consent screen between the agent and your account. Only one of them you can inspect.

	Official Google servers	taylorwilsdon/google_workspace_mcp
Who runs it	Google (remote endpoint)	You (self-hosted)
Availability	Developer Preview Program only	Open to anyone, MIT license
Coverage	Gmail, Drive, Docs, Sheets, Slides, Calendar, Chat, People	Those 8 plus Forms, Tasks, Contacts, Search and Apps Script
Auth	OAuth 2.0, your own client ID and secret	Your own OAuth client; OAuth 2.1 PKCE for multi-user
Scope control	Whatever scopes you add to the consent screen	OAuth scopes, plus tool tiers and a --read-only flag

Gmail MCP server: the tool list is the real security boundary

Read Google’s own reference for the Gmail MCP server and the first thing that stands out is what is missing. The tool list is create_draft, get_thread, label_message, label_thread, list_drafts, list_labels, search_threads, unlabel_message and unlabel_thread. There is no send_message. There is no delete. An agent wired to Google’s own Gmail MCP server can read your mail, label it and write a draft. It cannot send anything without you opening Gmail and clicking send yourself.

The scopes back that up: Google’s setup guide has you add exactly gmail.readonly and gmail.compose, not gmail.send and not the catch-all mail.google.com scope. That is not an accident. It is the single most useful fact in this whole space: the people who built the official Gmail MCP server decided an agent should draft, not send.

Open-source Gmail-only servers do not all make that choice. The most-starred one on GitHub, GongRzhe/Gmail-MCP-Server at 1,164 stars, is archived and has not shipped a commit since August 2025. If you go looking for “the” Gmail MCP server on GitHub, the top result by stars is the one you should trust least, because nobody is reviewing its dependencies anymore.

The auth model decides whether this is safe

Every Workspace MCP server, official or not, puts the same three decisions in front of you: whose OAuth client, which scopes, and single-user or multi-user.

Use your own OAuth client, never a shared one. The official Google servers and the self-hosted one both want a client ID and secret from your own Google Cloud project’s OAuth consent screen, not a vendor’s. That client is the thing an attacker wants, and it is the thing you can revoke without touching anything else.

Grant read scopes by default. Google’s own setup guide adds gmail.readonly, drive.readonly, calendar.events.readonly and the equivalent for every other product before it adds any write scope. The write scopes (gmail.compose, drive.file, documents) exist, and the MCP server’s own tool list is still the second gate behind them: even with gmail.compose granted, the official server has no tool that sends.

Single-user versus multi-user is a deployment decision, not a security one. The official Google servers and google_workspace_mcp’s OAuth 2.1 PKCE mode both let several people authenticate against one running server with their own tokens, isolated from each other. That is the right shape for a team. It is also more moving parts than most individual setups need. If it is just you and one MCP client, the single-user “confidential client” flow is fewer things that can go wrong.

Wiring a Workspace source into Hermes

Hermes Agent takes MCP servers under mcp_servers in ~/.hermes/config.yaml. An HTTP-based Workspace server (your own google_workspace_mcp deployment, or Google’s remote endpoints) goes in by URL:

mcp_servers:
  workspace:
    url: "http://localhost:8000/mcp"
    trust: untrusted

trust: untrusted is the one key that matters most here. Per Hermes’ own MCP config reference, any tool on an untrusted server that lacks a readOnlyHint: true annotation requires approval through Hermes’ standard approval surface before it runs, on every messaging platform. Mark a Workspace source untrusted and reads flow through while every draft, label change or event creation stops and asks first, no matter how the server itself describes its own tools.

The same thing from the CLI, then a check before any session gets access to it:

Register and test the server in Hermes

1. Add the server

   $ hermes mcp add workspace --url "http://localhost:8000/mcp" --auth oauth

2. Connect and list its tools

   $ hermes mcp test workspace

hermes mcp test connects, lists the discovered tools, and exits non-zero if the connection or the config is wrong.

Wiring it into Claude Code

Claude Code’s current syntax, per Anthropic’s own docs, is claude mcp add --transport http <name> <url>, with an optional --header for a bearer token:

Register the server in Claude Code

1. $ claude mcp add --transport http workspace http://localhost:8000/mcp

That matches google_workspace_mcp’s own README exactly: run the server in HTTP mode, then register it with that one command. For Google’s official remote endpoints, Claude.ai and Claude Desktop take the OAuth client ID and secret as a custom connector in their settings instead, since those are hosted by Google, not something you point a local command at.

The platform is not the source

Hermes has a plugins/platforms/email adapter: IMAP in, SMTP out, configured through platforms.email in config.yaml or EMAIL_* environment variables. That is a gateway. It lets you talk to Hermes by sending it an email, the same way the Telegram or Slack gateways let you talk to it from a chat app. It has nothing to do with Gmail MCP.

A Gmail MCP server is a source. It lets Hermes read and act on your Gmail account as data, the way a GitHub MCP server lets it read issues. One is how you reach the agent. The other is what the agent can reach. Confusing the two gets you either an agent that cannot act on your inbox at all, or one that can read every email you have but that you can never message directly, and neither failure mode announces itself until you go looking for the missing piece.

Where this fits in a daily briefing

At my day job, a Hermes cron job writes me a daily briefing of what is happening across the company. It reads the company’s MCP servers for Slack, Google Workspace, Git and Confluence or Jira, and it is organized by six senses: self, them, trend, frontier, community, client. Workspace is one source among several there, not the whole job. A mailbox tells you what people are asking for, a chat tool what they are reacting to, a repo what actually shipped. The senses are the questions. Each one pulls from whichever sources answer it, and the MCP server is the bridge from the question to the data.

Before you point an MCP server at your inbox

• ✓Required:
  You created your own OAuth client, not a shared or vendor one.That client is what you revoke if anything goes wrong. A client you do not control is a client you cannot rotate.
• ✓Required:
  You granted read scopes first, write scopes only if a tool actually needs them.gmail.readonly and gmail.compose, not mail.google.com. Check the scope list against the tool list, not against what sounds safe.
• ✓Required:
  The server's write-capable tools require approval, not just a scope check.trust: untrusted in Hermes, or the equivalent approval gate in whatever runs the agent. Two gates beat one.
• ✓Required:
  You checked when the server last shipped a commit.Star count is popularity, not maintenance. An archived Gmail MCP server with a thousand stars is still archived.
• ✓Required:
  You know whether the agent can send, not just read and draft.Google's own Gmail MCP server cannot send. If the one you are using can, that is a deliberate step up in blast radius.

Google Workspace MCP and Gmail MCP, quick answers

What is Google Workspace MCP?+

It is not one server. Google ships its own remote MCP servers for Gmail, Drive, Docs, Sheets, Slides, Calendar, Chat and People, gated behind its Developer Preview Program. Separately, open-source servers such as taylorwilsdon/google_workspace_mcp cover the same ground and more, self-hosted, with no gate.

What is the Gmail MCP server?+

Google's own Gmail MCP server exposes nine tools: searching and reading threads, listing and creating drafts, and managing labels. It has no send tool and no delete tool.

Open-source Gmail-only servers vary. Check their tool list and their scopes before assuming the same restraint.

Is Google Workspace MCP safe?+

It is as safe as the OAuth client, the scopes and the tool list you allow. Google's own setup docs warn about indirect prompt injection from emails and documents the agent reads, and recommend reviewing every action. Read-only scopes and an untrusted trust tier on the MCP config turn that warning into a control.

Can I use Gmail MCP with Claude Code or Claude Desktop?+

Yes, two different ways. Claude Code registers any HTTP MCP server with claude mcp add --transport http <name> <url>, which works for a self-hosted server like google_workspace_mcp.

Claude.ai and Claude Desktop connect to Google's official remote Gmail MCP server as a custom connector, through Settings, Connectors, with your own OAuth client ID and secret.

How do I add a Google Workspace MCP server to Hermes Agent?+

Add an entry under mcp_servers in ~/.hermes/config.yaml with a url for an HTTP server, or use hermes mcp add <name> --url <endpoint> --auth oauth from the CLI. Set trust: untrusted so every write-capable tool call needs approval before it runs.