google-workspace-mcp

Ein Set aus fünf unabhängigen Remote-MCP-Servern für Google Workspace: Gmail, Google Calendar, Google Drive, Google Sheets und Google Docs.

Status: pre-alpha. Das Projekt befindet sich in aktiver Entwicklung; öffentliche Schnittstellen und Konfiguration können sich bis zum ersten stabilen Release ändern.

Die Server sind bewusst getrennt. Ein Client oder Projekt bindet nur den Dienst ein, den es benötigt, und erhält ein Token, das genau für diesen Dienst gilt: Ein Gmail-Token öffnet kein Drive. Gemeinsam bleiben das Repository, die Infrastrukturbibliotheken, das Autorisierungs-Framework und das Bereitstellungsverfahren.

Dienste

Jeder Dienst ist ein eigener Prozess, ein eigener MCP-Endpunkt, eine eigene Tool-Registry, ein eigener Satz von Google-Berechtigungen und ein eigener Speicher für Anmeldedaten.

Zwei Ebenen der Autorisierung

Sie sind unabhängig und vermischen sich nicht.

Client → Dienst. Der MCP-Client durchläuft OAuth 2.1 mit PKCE und dynamischer Registrierung. Das ausgestellte Token ist an eine einzige Ressource gebunden und wird über ein rotierendes Refresh-Token mit Wiederverwendungserkennung erneuert.

Dienst → Google. Der Dienst greift im Namen des Eigentümers über ein langlebiges Refresh-Token auf die Google-Produkt-APIs zu und erneuert das Access-Token selbst. Das Google-Token wird dem Client unter keinen Umständen zurückgegeben.

Die offiziellen MCP-Endpunkte von Google befinden sich in der Developer Preview und werden hier nicht verwendet: Die Aufrufe gehen an die stabilen Produkt-APIs.

Voraussetzungen

• Python 3.14, wird mit uv installiert; der Systeminterpreter bleibt unberührt

• uv

• ein Google Cloud-Projekt mit aktivierten APIs der fünf Dienste und einem OAuth-Client

Installation

uv sync --dev

Prüfungen

uv run --no-sync pytest -q
uv run --no-sync ruff check .
uv run --no-sync ruff format --check .
uv run --no-sync mypy src

Das Flag --no-sync ist bei der Prüfung der Abhängigkeitsversionen erforderlich: Ohne es synchronisiert uv run die Umgebung neu aus der Lock-Datei und gibt die gepinnte Version statt der tatsächlichen zurück, wodurch eine bekanntermaßen defekte Paketversion einen grünen Lauf ergibt.

Herkunft

Das Projekt adaptiert den OAuth-2.1-Kern aus jimprosser/obsidian-web-mcp unter der MIT-Lizenz; vollständige Informationen finden sich in NOTICE.

Dem Downstream-OAuth-2.1 liegt die Revision 7e6a52d791a50e3bd533df1060217973ab5be1c8 zugrunde. Danach wurden in den Kern eigene Korrekturen eingebracht: am Lebenszyklus von Clients und Tokens, an der Rotation von Refresh-Tokens, an der Wiederverwendungserkennung und an der Kanonisierung von resource.

Der Domänenteil des ursprünglichen Projekts — die Arbeit mit dem Obsidian-Vault und die Synchronisation über Git — wurde nicht übernommen.

Hier wird mcp>=2,<3 verwendet: Das in MCP 2.0 entfernte Paket mcp.server.fastmcp wird nicht benötigt, und die eigene Komposition basiert auf mcp.server.mcpserver.

Lizenz

MIT, siehe LICENSE.