Google Workspace MCP: Official vs Community Server

Google now runs official first-party Workspace MCP servers — one per product, at addresses like gmailmcp.googleapis.com. They entered public developer preview in spring 2026 (announced 22 April, public preview from 1 May) and remain preview-gated today. The community server most teams already run, taylorwilsdon/google_workspace_mcp, predates them by months. The official set covers five Workspace surfaces; the community server covers twelve. Which one you should run comes down to a single question: how many different people's Google accounts does your agent act on behalf of?

We run the community server in production behind a governed gateway, for multiple operators, and have filed 14 friction issues against Google Workspace tooling since 26 May 2026. This is the coverage scorecard and what the gaps cost.

The scorecard

Every business tool now exists at three separate surfaces: the UI a human clicks, the API a client calls, and the MCP an agent calls. They do not converge automatically. Each cell below is scored 0–4, where 0 means not addressable at that layer and 4 means an agent succeeds on the first call from the tool description alone. The MCP row scores the community server as we run it.

Layer	Read	Write	Relationship	Workflow	Audit / History
UI	4	4	4	3	3
API	4	4	4	3	3
MCP	2	2	2	2	0

UI and API rows are assessed against Google's published product and API surface. The MCP row is scored from production use.

The coverage gap — max(UI, API) − MCP — is 2 across read, write and relationship, and 3 on audit. A gap above 1 means custom wrappers are effectively mandatory today. We wrote them.

Official vs community: the surface count

Google's configuration guide lists one dedicated remote MCP server per product, all marked Developer Preview — using them requires enrollment in the Workspace Developer Preview Program, and the endpoints are versioned preview paths (/mcp/v1). The community server is a single process exposing every surface at once.

Surface	Official server	Community server
Gmail	gmailmcp.googleapis.com	yes
Drive	drivemcp.googleapis.com	yes
Calendar	calendarmcp.googleapis.com	yes
Chat	chatmcp.googleapis.com	yes
Contacts / People	people.googleapis.com	yes
Docs	—	yes
Sheets	—	yes
Slides	—	yes
Forms	—	yes
Tasks	—	yes
Apps Script	—	yes
Custom Search	—	yes

Five versus twelve. If your agent needs to touch a Doc, a Sheet, a slide deck, a Form response, a Google Task, or an Apps Script function, the official servers do not reach those surfaces yet and the community server does.

There is a second, less obvious difference. The official servers are one connector per product. Connecting an agent to Gmail, Drive, Calendar and Chat means adding four separate custom connectors, each with its own OAuth client configuration. The community server is one endpoint for all of them.

The plan requirement

Per Google's own documentation, using the official remote Workspace MCP servers with Claude.ai or Claude Desktop requires a Claude Enterprise, Pro, Max, or Team plan. There is no free-tier path. The community server has no such constraint because you host it yourself.

The real dividing line: multi-operator OAuth

This is the part that decides the question for anyone running agents on behalf of more than one person.

Both server families authenticate a user. Neither has an opinion about what happens when eight different operators — a sales agent, a marketing agent, an executive assistant agent, each running as a different human's identity — need to hit Gmail through the same infrastructure without seeing each other's mail.

The community server gets closest. Setting MCP_ENABLE_OAUTH21=true and WORKSPACE_MCP_STATELESS_MODE=true runs it in stateless mode over streamable-HTTP, where it holds no credentials at all and accepts a per-request bearer token. That turns the server into a pure execution surface and moves the entire identity problem upstream — which is exactly what you want, because it means the identity problem becomes yours to solve properly rather than the vendor's to solve badly.

In our deployment the gateway holds the encrypted refresh tokens, resolves the calling operator on every request, mints a fresh access token, and injects it as the bearer. Operators authorize their own account once; the gateway remembers which connection belongs to whom. An operator with no connection gets a structured needs_reauth response telling them to run the consent flow, rather than a silent failure or — far worse — somebody else's inbox.

No MCP server in either family ships this. Every guardrail described above is gateway-added. That is the honest state of the Workspace MCP layer in 2026: the tools are real, and the multi-tenancy is bring-your-own.

Failure modes we hit

Scored against five failure modes. We did not find all five, which is itself worth reporting.

Unshaped — severe. The dominant failure by a wide margin. search_gmail_messages returns message IDs and web links and nothing else, so an agent triaging an inbox must fetch every full body just to learn who sent what. Those bodies then overflow to a file the agent cannot read. Our own agents filed this defect four separate times in seven days before we shipped an override. It has its own post, because the cost of a tool that returns correct data at the wrong shape is badly underrated.

Ungated — severe. One open P1 issue: get_gmail_message_content and get_gmail_messages_content_batch accept no task_id parameter, so a gateway that governs tool calls by intent cannot govern those two. An agent can read mail outside any declared task. There is no vendor-side fix; the tool signature has to change or the tool has to be wrapped.

Undescribed — mild. send_gmail_message accepts an HTML body, but the parameter that enables it (body_format="html") was undocumented in the description the agent reads. Agents passed HTML and it arrived as visible tags. Cheapest possible fix, real cost while it lasted.

Underexposed — mild. Gmail attachment content was not retrievable through the exposed tool set at all, despite the API supporting it.

Uncontextualized — not observed. Workspace's data model is familiar enough that agents did not burn round-trips learning it. Credit where due.

Receipts

Fourteen issues filed by our own agents against Google Workspace tooling between 26 May and 31 July 2026. Nine concern Gmail. The distribution is the finding: Drive, Docs, Sheets and Calendar have been comparatively quiet, and Gmail has been a sustained source of friction.

Two remain open and unresolved at the vendor layer: the ungatable Gmail content tools, and a proxy that intermittently throws unhandled errors in a TaskGroup on the first call of a session.

Implementation verdict

We run Google Workspace in production, through the community server in stateless OAuth 2.1 mode, behind a gateway that adds per-operator credential resolution and three Python override tools.

Reads and writes both work once wrapped. Unwrapped, Gmail is the weak surface and everything else is serviceable. The three overrides we consider non-negotiable: a search tool that returns sender and subject, a send tool that formats HTML server-side, and per-operator credential resolution so an agent cannot act as the wrong person.

Would we deploy it inside a governed multi-operator environment? Yes, and we do — but only with the wrapper layer. Deployed raw, on a single shared credential, it is a data-boundary incident waiting for a busy week.

Which server should you pick? If you are one person connecting one Google account to Claude Desktop, and you have developer preview access, the official servers are worth a look: they are first-party, maintained by Google, and the narrower surface is a feature rather than a limitation. If you are running agents for a team, need Docs, Sheets, Slides, Forms, Tasks or Apps Script, or need one endpoint instead of five connectors, the community server is still the only real option — and you will be writing the multi-tenancy layer yourself either way.

Related

• Gmail MCP Search Returns IDs, Not Senders — the deepest failure on this surface, and the fix
• Google Search Console MCP: 5 Setup Errors — the same credential, a much rougher integration
• Google Analytics MCP: What the Official Server Does — the other Google MCP we run
• Claude Code MCP Scopes: Local, Project, User + a 4th Layer — where MCP server configuration actually lives on disk
• Isolate Claude MCP Connections Per Client — why one shared credential across clients is the failure mode to design against