google-workspace-mcp

Ein Projekt zum Aufbau von fünf unabhängigen Remote-MCP-Servern für Google Workspace: Gmail, Google Kalender, Google Drive, Google Tabellen und Google Docs.

Status: Pre-Alpha. Die MCP-Server sind noch nicht funktionsfähig. Das Repository enthält derzeit das Paketgerüst, fünf Platzhalter-Einstiegspunkte, den nachgelagerten OAuth-Zustandskern und unveränderliche Konfiguration pro Dienst.

Aktueller Status

Implementiert:

• ein Python-Paket mit fünf Konsolen-Einstiegspunkten;

• SQLite-gestützter nachgelagerter OAuth-Zustand;

• OAuth-Client-Registrierung und PKCE;

• Token-Bindung an eine kanonische resource;

• Aktualisierung von Refresh-Tokens, Replay-Erkennung und Familien-Widerruf;

• unveränderliche Zustands-Eigentumsmetadaten für Dienst und Ressource;

• unveränderliche pro-Dienst-Konfiguration mit strenger Port- und Token-TTL-Validierung.

Alle fünf Konsolen-Einstiegspunkte sind Platzhalter und beenden mit einer Meldung, dass der Dienst nicht gebaut ist. Der HTTP/MCP-Transport, die Google-API-Integration, die Dienstwerkzeuge und die Bereitstellungskonfiguration sind noch nicht implementiert.

Related MCP server: google-workspace-mcp-advanced

Geplante Dienste

Die Tabelle beschreibt den Zielumfang. Diese Funktionen sind noch nicht verfügbar.

In der Zielarchitektur läuft jeder Dienst als separater Prozess mit eigenem MCP-Endpunkt, eigener Werkzeugregistrierung, eigenen Google-OAuth-Bereichen, eigenen Google-Anmeldedaten und eigenem nachgelagerten OAuth-Zustand.

Ziel-Autorisierungsarchitektur

Das Design verwendet zwei unabhängige Ebenen:

Client zu Dienst. Der MCP-Client verwendet OAuth 2.1 mit PKCE. Jedes Zugriffstoken ist an eine resource gebunden, und Refresh-Tokens rotieren mit Replay-Erkennung.

Dienst zu Google. Jeder Dienst verwendet separate Google-Anmeldedaten und die minimal erforderlichen OAuth-Bereiche. Google-Refresh-Tokens werden niemals an MCP-Clients zurückgegeben.

Nur der Zustandskern der ersten Ebene existiert heute. HTTP-Endpunkte und die zweite Autorisierungsebene sind nicht implementiert.

Technologie

• Python 3.14

• uv

• MCP Python SDK

• Pydantic

• Google API Python Client

Entwicklung Voraussetzungen

• Git

• Python 3.14

• uv

Ein Google-Cloud-Projekt und OAuth-Client werden nach der Implementierung der Google-API-Integration erforderlich sein. Die aktuelle Version verwendet sie nicht.

Entwicklungseinrichtung

git clone https://github.com/hawkxdev/google-workspace-mcp.git
cd google-workspace-mcp
uv sync --dev

Die virtuelle Umgebung muss nicht aktiviert werden. Führen Sie Befehle über uv run aus.

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 erforderlich, wenn die installierte Abhängigkeitsversion überprüft wird. Ein einfaches uv run kann die Umgebung aus der Sperrdatei neu synchronisieren.

Struktur

Mitwirken

Das Projekt befindet sich in der frühen Entwicklung. Bevor Sie eine wesentliche Änderung vornehmen, öffnen Sie ein Issue, das das vorgeschlagene Verhalten beschreibt. Änderungen dürfen die fünf Dienste nicht in einen Prozess zusammenführen, Anmeldedaten zwischen Diensten teilen oder eine OAuth-Umgehung einführen.

Herkunft

Das Projekt passt den OAuth-2.1-Kern von jimprosser/obsidian-web-mcp unter der MIT-Lizenz an. Siehe NOTICE für Details.

Der nachgelagerte OAuth-2.1-Kern basiert auf Revision 7e6a52d791a50e3bd533df1060217973ab5be1c8. Er enthält zusätzliche Korrekturen für Client- und Token-Lebenszyklen, Refresh-Token-Rotation, Replay-Erkennung und resource-Kanonisierung.

Die Obsidian-Speicher- und Git-Synchronisationsfunktionalität des ursprünglichen Projekts wurde nicht kopiert.

Dieses Projekt verwendet mcp>=2,<3. Das in MCP 2.0 entfernte Paket mcp.server.fastmcp ist nicht erforderlich; die zukünftige Zusammensetzung wird mcp.server.mcpserver verwenden.

Autor

Sergey Sokolkin (@hawkxdev)

Lizenz

MIT, siehe LICENSE.