All MCPsGoogle Workspace MCP
Productivity

Google Workspace MCP

This Google Workspace MCP server brings Gmail, Drive, Calendar, Docs, Sheets, Slides, Forms, Tasks, Contacts, and Chat behind a single integration, with over 120 tools. It handles OAuth 2.1 multi-user authentication, a read-only mode, and stateless container deployment.

When to use it

Useful for automating email management, shared documents, or scheduling directly from Claude.

Third-party projects · manually verified · not maintained by Educasium

Google Workspace MCP Server, published by Taylor Wilsdon, connects AI assistants to Gmail, Drive, Calendar, Docs, Sheets, Slides, Forms, Tasks, Contacts, Chat, Google Search, and Apps Script. The taylorwilsdon/google_workspace_mcp repository announces 120+ tools, multi-user OAuth 2.1, progressive tool tiers, read-only mode, a CLI, and stateless container deployment. In the GitHub check on August 26, 2026, the repository was MIT licensed, had 3,073 stars and 964 forks, and pyproject.toml listed workspace-mcp 1.25.1 with Python 3.10 or newer.

For Educasium, this connector matters because it touches an organization's full document environment. It can read and act on email, documents, spreadsheets, calendars, and shared files. The useful approach is cautious: the real topic is not only productivity, but control over scopes, writes, and sensitive data.

Contents

  1. What Google Workspace MCP does
  2. Services and tool surface
  3. Authentication and server modes
  4. Security, local files, and prompt injection
  5. Tiers, read-only mode, and surface reduction
  6. Comparison with Excel and Microsoft 365
  7. Educasium position

What Google Workspace MCP Does

Key point: Google Workspace MCP gives an assistant one interface to twelve Google services, with 120+ announced tools. It is a digital workplace integration, not just a Gmail connector.

A cross-service MCP

The README presents the server as a way to control Google Calendar, Drive, Gmail, Docs, Sheets, Slides, Forms, Tasks, Contacts, Chat, Search, and Apps Script. The service table includes Gmail with search, send, drafts, labels, and attachments; Drive with search, creation, sharing, and Office imports; Docs with editing, styling, tables, comments, and export; Sheets with ranges, tables, formatting, and conditional rules.

That breadth enables real workflows: find an email, extract an attachment, create a summary document, update a sheet, schedule a meeting, and prepare a message. It also increases risk: every added service expands the data surface the assistant can read or modify.

What to avoid

The README uses ambitious language. Educasium should keep verified facts without turning superlatives into guarantees. Saying 120+ tools, OAuth 2.1, read-only mode, and stateless deployment is useful. Saying it replaces document governance would be false.

An assistant connected to Google Workspace can help with tasks, but it does not automatically know which documents are confidential, which attachments are sensitive, or which emails contain hostile instructions.

Services And Tool Surface

Key point: the surface covers communication, files, office documents, forms, tasks, contacts, search, and Apps Script. That richness requires a tool-selection strategy.

Covered services

The README lists Gmail, Drive, Calendar, Docs, Sheets, Slides, Forms, Tasks, Contacts, Chat, Custom Search, and Apps Script. The displayed service counts give an order of magnitude, such as 15 Gmail tools, 16 Drive, 7 Calendar, 19 Docs, 14 Sheets, 7 Slides, 6 Forms, 6 Tasks, 8 Contacts, 6 Chat, 2 Custom Search, and 15 Apps Script.

These numbers are useful, but they should be read as of the verification date. An active repository can change quickly. The sourcesCheckedAt field makes that freshness boundary visible and ties the claims to the README.

Workflow examples

A simple teaching case: read recent project emails, find the Drive folder, create a Google Doc meeting note, add one tracking row in Sheets, and propose a Calendar slot. A more advanced case: generate a form, analyze responses in Sheets, then prepare a Chat message.

These scenarios should start in read-only mode. The learner should see which data the assistant consults before enabling writes such as sending email, sharing files, or modifying documents.

Authentication And Server Modes

Key point: the integration depends on your Google Cloud project, your OAuth client, and the scopes you authorize. The README emphasizes that OAuth credentials stay under user or organization control.

OAuth and deployment

The quick start requires a Google Cloud OAuth client and the APIs needed for the services used. The server can run over stdio for legacy clients or Streamable HTTP for modern clients. The README documents OAuth 2.1 with PKCE, stateless deployment, reverse proxy setup, credential storage, and advanced modes.

The verified pyproject shows Python >=3.10 and dependencies consistent with FastAPI, FastMCP, Google libraries, OAuth, cryptography, PDF handling, and parsing. The package exposes workspace-mcp and workspace-cli.

CLI and Code Mode

workspace-cli lists and calls tools against a running server with encrypted OAuth token caching. The README warns not to use uvx workspace-cli because an abandoned PyPI package uses that name. That is a useful technical note because it prevents a silent wrong install.

For Educasium, the CLI shows that MCP can be used beyond chat. A workflow can be conversational, scriptable, or integrated into a developer environment.

Security, Local Files, And Prompt Injection

Key point: the README explicitly names prompt injection risk in emails, documents, and events. That is central to any page about connected productivity tools.

Data and network

The security section says that, by default, the server sends no data anywhere except Google's APIs, on behalf of the authenticated user, with configured OAuth credentials. It also says there is no usage reporting or built-in telemetry except optional tracing configured by the user.

That does not remove risk. Data sent to Google remains subject to Google terms, and responses are read by the assistant. Emails, documents, and calendar invites can contain hostile instructions. The prudent method separates read, summarize, and write steps.

Local files

The README explains that local file reads default to the managed attachment directory, and validate_file_path still blocks .env, ~/.ssh, ~/.aws, and similar sensitive paths even if ALLOWED_FILE_DIRS is broadened.

This detail matters. It shows the project thinks about local risk, not only Google scopes. Educasium should present it as a useful guardrail while warning that broadening allowed directories should be rare and justified.

Tiers, Read-Only Mode, And Surface Reduction

Key point: core, extended, complete, tool selectors, read-only mode, and per-service permissions reduce the model's exposed surface. This is the governance part of the connector.

Tiers and selection

The README describes three tiers: core for essential tools, extended for management operations, and complete for everything. It also allows selecting services with --tools, using --read-only, setting per-service permissions, and disabling individual tools.

In an organization, do not load everything by default. An assistant asked to summarize emails does not necessarily need to edit Drive files or send Chat messages. Surface reduction is both security and clarity.

Read-only first

Read-only mode is the right teaching starting point. It lets the assistant find, summarize, and cross-reference information without irreversible effects. Writes should come after workflow validation, with human confirmation for sending email, sharing files, or modifying documents.

That progression respects the client lifecycle: connection, discovery, reading, synthesis, proposal, validation, and write action.

Comparison With Excel And Microsoft 365

Key point: Google Workspace MCP fits Google-centered organizations; Excel MCP fits local .xlsx files; Microsoft 365 MCP follows Microsoft Graph.

NeedGoogle Workspace MCPExcel MCPMicrosoft 365 MCP
Gmail, Drive, Docs, SheetsStrong fitOut of scopeOut of scope
Manipulate a local .xlsxIndirectStrong fitPossible via OneDrive/Graph
Outlook, Teams, SharePointOut of scopeOut of scopeStrong fit
Start read-onlyYesFile copiesYes
Permission governanceGoogle OAuthFile rootMicrosoft Graph scopes

Choose by organization

The choice should follow the client's real environment. A school or agency living in Google Workspace benefits from a cross-service connector. A team exchanging standalone Excel files may prefer Excel MCP. A Microsoft organization should prefer Microsoft 365 MCP to respect accounts, groups, SharePoint, and Teams.

Educasium Position

Key point: Educasium teaches Google Workspace MCP as governed organizational integration, not magic access to every document. Permissions are the central lesson.

What to show

A good workshop starts with a narrow scope: Gmail and Drive in read-only mode. The assistant finds emails, summarizes attachments, and prepares an unsent draft. Only then should Calendar, Docs, or Sheets be added if the case requires them.

That progression shows the real work with MCPs: give enough access to be useful, but no more. Readers also need to learn who authorized access, which services stayed enabled, and which write actions remain blocked until human confirmation. A powerful productivity connector needs a clear scope, validation, and logging policy. That record supports internal audits and lowers the chance that useful automation turns into excessive access.

Frequently asked questions

Does Google Workspace MCP access my whole Google account?

It accesses the services and scopes you configure and authorize. The README emphasizes OAuth, tool tiers, service selection, read-only mode, and per-service permissions. The right practice is to start with the smallest scope and add only what is needed.

Is read-only mode enough to work?

For discovery, search, summarization, and preparing drafts, often yes. It will not finalize actions such as sending email or modifying a document. That is exactly why it is useful at the start: it tests the workflow without irreversible effects.

Why does prompt injection matter here?

Because emails, documents, and events can contain text controlled by other people. That text can try to influence the assistant. When the assistant has write or sharing tools, separate reading from action, limit scopes, and require human validation.