google_workspace_mcp: 120+ Workspace-Tools hinter einem MCP-Server, mit OAuth 2.1 für mehrere Nutzer

Zwölf Dienste, ein Server: das Problem hinter dem Projekt

MCP-Clients wie Claude Desktop oder ChatGPT Developer Mode sprechen mit einzelnen Servern, die jeweils einen klar umrissenen Werkzeugkasten anbieten. Wer Gmail, Kalender, Drive, Docs, Sheets, Slides, Forms, Tasks, Contacts und Chat gleichzeitig nutzen will, müsste ohne diesen Server mehrere MCP-Prozesse parallel konfigurieren, jeder mit eigener Authentifizierung. google_workspace_mcp bündelt diese Dienste hinter einer Instanz. Die Zielgruppe sind laut README zwei Gruppen: einzelne Nutzer, die ihren gesamten Workspace per natürlicher Sprache steuern wollen, und Organisationen, die einen zentralen, mehrbenutzerfähigen Zugang für alle Mitarbeiter bereitstellen möchten. Der zweite Fall ist der interessantere, weil er die eigentliche Design-Entscheidung erklärt: OAuth 2.1 mit mehreren Nutzern statt eines einzelnen Tokens, das irgendwo auf der Platte liegt. Freie Google-Konten werden ebenso unterstützt wie Workspace-Pläne, wobei Chat und Spaces laut README erweiterte App-Optionen voraussetzen.

Transport, Tool-Tiers und der Weg einer Anfrage

Der Server spricht zwei Transportwege. Lokal läuft er über stdio für ältere Clients, die keinen HTTP-Endpunkt ansprechen können. Remote läuft er über streamable HTTP nach der aktuellen MCP-Spezifikation, was Voraussetzung für den Mehrbenutzerbetrieb ist. Die Werkzeuge sind in drei progressive Tool-Tiers gegliedert, sodass ein Client nicht sofort alle über 120 Tools sieht, sondern schrittweise mehr freischalten kann. Dazu kommt ein Read-only-Modus, der schreibende Operationen unterbindet. Der Datenfluss bleibt dabei eng: laut README sendet der Server standardmäßig keine Daten an andere Stellen als an Googles APIs, im Auftrag des authentifizierten Nutzers und mit den OAuth-Client-Credentials des Betreibers. Es gibt kein Usage-Reporting, keine Analytics und keinen Lizenzserver; optionales OpenTelemetry-Tracing ist nur aktiv, wenn es explizit konfiguriert wird. Für den Dateizugriff nennt das README eine Einschränkung: lokale Dateilesevorgänge sind standardmäßig auf ein verwaltetes Attachment-Verzeichnis beschränkt, und `validate_file_path()` blockiert weiterhin `.env*`-Dateien sowie gängige Credential-Ablagen wie `~/.ssh/` und `~/.aws/`, selbst wenn `ALLOWED_FILE_DIRS` erweitert wird.

Installation und Konfiguration: was tatsächlich in der Hand liegt

Das Paket liegt auf PyPI als `workspace-mcp`, Python 3.10 oder neuer wird vorausgesetzt. Der README verweist für den Einstieg auf eine Quick-Start-Seite mit Screenshots, die die Einrichtung des Google-Cloud-Projekts, die Credentials und die Client-Verbindung abdeckt. Diese Schritte sind nicht optional: ohne eigenes GCP-Projekt, eigenen OAuth-Client und passende Redirect-URIs startet der Server nicht sinnvoll. Für den Betrieb relevant sind die Umgebungsvariablen, die die Deployment-Dokumentation vollständig auflistet, darunter `ALLOWED_FILE_DIRS` für erweiterte Dateipfade. Wer den Server hinter einem Reverse Proxy betreibt, findet dort außerdem nginx-Konfiguration, Origin-Validierung und Optionen für Credential-Store-Backends wie GCS mit CMEK. Ein Gateway-Passthrough für Identität ist ebenfalls dokumentiert. Für Claude Code und Codex nennt das README einen eigenen CLI- und Code-Modus. Wer den Server nicht selbst betreiben will, kann laut README eine gehostete Instanz ab 5 US-Dollar pro Monat buchen; das ist ein kommerzielles Angebot neben dem MIT-lizenzierten Code.

Der stateless Modus und warum er nicht überall passt

Für abgeschottete Container-Umgebungen bietet der Server einen stateless Modus ohne Schreibzugriffe auf die Platte. Das ist eine bewusste Einschränkung: Zustand, der sonst lokal läge, muss dann woanders hin, etwa in ein externes Credential-Store-Backend. In dieser Konstellation hängt die Betriebsfähigkeit an der Verfügbarkeit dieses Backends. Wer den stateless Modus ohne externen Store fährt, verliert vermutlich die Fähigkeit, Sitzungen über Neustarts hinweg zu erhalten; das README beschreibt den Modus als Option für gesperrte Container, nennt aber keine Details zum Sitzungsverhalten. Hier ist Vorsicht angebracht: Die Materialbasis erlaubt keine Aussage darüber, welche Funktionen im stateless Betrieb tatsächlich entfallen. Ein weiterer Punkt, der in der Praxis oft unterschätzt wird, sind die OAuth-Scopes. Der Server kann nur so viel, wie die Scopes hergeben, und die Auswahl liegt beim Betreiber. Ein restriktiv konfigurierter Client führt dazu, dass einzelne Tools zur Laufzeit scheitern, obwohl sie im Tool-Katalog auftauchen.

Read-only-Modus und Dateipfad-Blockade als Schutz, nicht als Garantie

Der Read-only-Modus ist die naheliegende Absicherung für den ersten Produktiveinsatz: Der Client darf lesen, aber nichts verändern. Das README beschreibt ihn als Modus, nicht als Sicherheitsgrenze gegen kompromittierte Clients. Wer einem Modell Schreibzugriff auf Gmail, Kalender und Drive gibt, gibt ihm faktisch die Berechtigungen des authentifizierten Nutzers, und die sind bei einem Workspace-Konto weitreichend. Die Dateipfad-Blockade deckt nur den lokalen Dateizugriff ab, nicht die Google-APIs. Sensible Pfade wie `~/.ssh/` und `~/.aws/` bleiben blockiert, auch wenn `ALLOWED_FILE_DIRS` breiter gesetzt wird. Das ist eine sinnvolle Voreinstellung, aber sie schützt nicht davor, dass ein Modell über die Drive-API an Dateien gelangt, für die der Nutzer ohnehin berechtigt ist. Die Sicherheitsentscheidung liegt damit beim Scope-Design, nicht beim Server.

Wo der Server das falsche Werkzeug ist

Für einen einzelnen Nutzer mit einem Desktop-Client ist der Funktionsumfang eher Ballast. Die Einrichtung eines Google-Cloud-Projekts, die Pflege der Redirect-URIs und die Auswahl der Scopes über zwölf Dienste hinweg kosten Zeit, die bei einem auf Gmail oder Kalender beschränkten MCP-Server entfällt. Auch wer nur lesend auf einen Dienst zugreifen will, braucht diese Komplexität nicht. Ein weiterer Fall: Umgebungen, in denen kein eigener OAuth-Client erlaubt ist oder in denen ausschließlich vorab genehmigte Integrationen verwendet werden dürfen. Der Server setzt voraus, dass der Betreiber eigene Credentials in seinem GCP-Projekt anlegt und kontrolliert. Fehlt diese Möglichkeit, ist das Projekt nicht nutzbar, unabhängig von der Lizenz. Und wer eine fertige, gewartete SaaS-Integration sucht, für den ist der gehostete Dienst des Anbieters die passendere Wahl als der Selbstbetrieb.

Alternativen und der Unterschied im Ansatz

Die naheliegende Alternative sind die eingebauten Integrationen von Claude und ChatGPT für Google Workspace. Der Unterschied liegt nicht im Funktionsumfang allein, sondern in der Architektur: Die eingebauten Integrationen laufen über die Infrastruktur des jeweiligen Anbieters, der Server hier läuft in der eigenen Umgebung mit eigenen Credentials. Das README behauptet, der Server könne Dinge, die diese Integrationen nicht abdecken, nennt aber keine konkreten Vergleichspunkte. Wer diesen Anspruch prüfen will, muss die Tool-Liste der eingebauten Integrationen gegen die 120+ Tools hier stellen. Ein zweiter Alternativtyp sind kleine, auf einen Dienst zugeschnittene MCP-Server. Sie sind schneller eingerichtet und haben einen kleineren Angriffsflächenumfang, decken dafür aber keine dienstübergreifenden Abläufe ab, etwa eine Suche, die Gmail und Drive gemeinsam durchsucht. Die Wahl hängt davon ab, ob der Anwendungsfall einen Dienst oder mehrere betrifft.

Wartung, Lizenz und was vor dem Rollout zu klären ist

Die Lizenz ist MIT, ohne Dual-Licensing, ohne kommerzielle Stufe, die Funktionen zurückhält, und ohne Contributor License Agreement. Kommerzielle Nutzung, Fork, Einbettung und Weitergabe sind damit möglich, solange die Attribution erhalten bleibt. Das ist für Procurement unkompliziert, weil keine Verhandlung nötig ist. Die Abhängigkeiten sind laut README durchgehend MIT, Apache 2.0 und BSD lizenziert, die vollständige Liste steht in `pyproject.toml` und ist in `uv.lock` gepinnt. Wer die Abhängigkeiten selbst prüfen muss, findet dort die Grundlage. Bei der Wartung ist die Release-Frequenz auffällig: Zwischen v1.25.1 und v1.26.0 liegen rund zwei Wochen, dazwischen ein Patch. Das deutet auf aktive Pflege hin, bedeutet aber auch, dass ein gepinnter Stand regelmäßig nachgezogen werden muss, besonders wenn Sicherheitsfixes in Abhängigkeiten anfallen. Vor dem Rollout zu klären sind drei Dinge: die vollständige Scope-Liste für die zwölf Dienste, die exakte Redirect-URI in der Client-Konfiguration und ob der Read-only-Modus die benötigten Leseoperationen abdeckt. Erst danach lohnt der Blick auf die Schreib-Tools.

Redaktionelles Fazit

Sinnvoll ist der Server für Teams, die einen zentral gehosteten Workspace-Zugriff für mehrere Nutzer brauchen und bereit sind, OAuth-Client, Scopes und Redirect-URIs selbst zu verwalten. Wer nur eine einzelne Person mit einem Desktop-Client verbinden will, fährt mit einem kleineren, auf einen Dienst zugeschnittenen MCP-Server deutlich einfacher. Vor dem Rollout zu prüfen: die vollständige Liste der OAuth-Scopes für die zwölf Dienste, der Ablauf der Redirect-URI in der eigenen Client-Konfiguration und ob der Read-only-Modus die benötigten Leseoperationen überhaupt abdeckt.

Offizielle Quellen

1. License: MIT
2. Project website
3. README
4. Releases
5. taylorwilsdon/google_workspace_mcp on GitHub