google_workspace_mcp : piloter Gmail, Drive et Calendar depuis un client MCP

Le problème concret : un client MCP ne voit rien de Workspace

Un assistant connecté via le Model Context Protocol ne sait rien faire de Gmail, Calendar ou Drive tant qu'un serveur ne lui déclare pas des outils correspondants. Les intégrations fournies par Claude ou ChatGPT couvrent une partie du terrain, mais le README affirme que ce projet va plus loin sur trois points : la prise en charge de plusieurs utilisateurs, des outils d'édition fins, et une couverture plus large des services Workspace. Le projet revendique douze services et plus de 120 outils derrière un seul serveur. La cible est donc double. D'un côté un développeur qui veut brancher son propre client MCP sur son compte Google. De l'autre une équipe qui préfère héberger une instance unique plutôt que laisser chacun configurer son connecteur. Le second cas est celui qui justifie vraiment le projet, parce qu'il demande une authentification multi-utilisateur et un déploiement centralisé, deux choses que les intégrations prêtes à l'emploi n'exposent pas.

Ce que le serveur expose réellement entre le client et les API Google

Le serveur se place entre le client MCP et les API Google. Il utilise OAuth 2.1 pour l'authentification, avec les identifiants OAuth de votre propre projet Google Cloud : le README insiste sur le fait que ces identifiants ne quittent pas votre environnement et que vous contrôlez les scopes accordés. Le transport se fait de deux manières. En stdio pour les clients qui ne parlent pas encore HTTP, et en streamable HTTP pour les autres, avec ce que le README décrit comme une implémentation complète de la dernière spécification MCP. Trois paliers d'outils progressifs permettent de n'exposer qu'une partie des 120+ outils, et un mode lecture seule existe séparément. C'est un point de conception important : un client qui n'a besoin que de lire un calendrier n'a aucune raison de voir les outils d'écriture, et le serveur permet de trancher cette question à la configuration plutôt que dans le prompt. Le mode sans état, lui, vise les environnements conteneurisés verrouillés où le disque n'est pas inscriptible. La contrepartie n'est pas détaillée dans le README : sans état signifie que l'état de session vit ailleurs, et le README renvoie à la page deployment pour les backends de stockage d'identifiants, notamment GCS et CMEK.

Mise en route : ce que le README donne et ce qu'il délègue

Le README ne contient pas de séquence d'installation complète. Il indique que le projet est publié sur PyPI sous le nom workspace-mcp, qu'il requiert Python 3.10 ou plus récent, et il renvoie à une page Quick Start pour la création du projet Google Cloud, les identifiants et la connexion du client, captures d'écran à l'appui. Les commandes d'installation et de lancement ne figurent donc pas dans le matériel fourni, et je ne les inventerai pas. Ce qui est documenté dans le dépôt, ce sont les variables d'environnement. Le README mentionne ALLOWED_FILE_DIRS pour élargir les répertoires autorisés en lecture, et validate_file_path() comme la fonction qui bloque malgré tout les fichiers .env* ainsi que les emplacements d'identifiants courants dans le répertoire personnel, comme ~/.ssh/ et ~/.aws/. Il mentionne aussi une référence complète des variables d'environnement sur la page deployment, sans la reproduire. Pour un déploiement derrière un reverse proxy, la même page couvre nginx, la validation d'origine et les backends de stockage d'identifiants. La dépendance complète est listée dans pyproject.toml et figée dans uv.lock, ce qui donne un point d'ancrage concret pour auditer la chaîne de dépendances avant installation.

Le mode lecture seule et le blocage de chemins : deux garde-fous à comprendre avant d'ouvrir l'accès

Le mode lecture seule est présenté comme une option, pas comme un défaut. C'est une distinction qui compte : un serveur qui expose les outils d'écriture de Gmail et Drive à un assistant doit être configuré sciemment, et le README ne dit pas explicitement quel est l'état par défaut des trois paliers d'outils. Le blocage de chemins est plus précis. Selon le README, les lectures de fichiers locaux sont par défaut confinées au répertoire de pièces jointes géré par le serveur, et validate_file_path() continue de refuser .env* ainsi que ~/.ssh/ et ~/.aws/ même si ALLOWED_FILE_DIRS est élargi. C'est un garde-fou en profondeur plutôt qu'un simple réglage, et c'est le genre de détail qui évite qu'une variable d'environnement trop permissive transforme un outil de productivité en lecteur de clés privées. La limite, elle, est que ce contrôle porte sur les chemins, pas sur le contenu : rien dans le README n'indique un filtrage des données renvoyées par les API Google elles-mêmes.

Là où le projet n'est pas le bon outil

Le coût d'entrée est réel. Il faut créer un projet Google Cloud, configurer un client OAuth, gérer les URI de redirection, et le README consacre une page entière aux erreurs OAuth et aux particularités des clients. Pour un utilisateur solo qui veut juste que son assistant lise son agenda, cette mise en place est disproportionnée par rapport à un connecteur déjà intégré. Le second cas défavorable est celui d'une organisation qui exige un support éditeur : ici, le mainteneur est unique, et rien dans le matériel fourni ne décrit de gouvernance, d'engagement de support ou de politique de compatibilité ascendante entre versions. Le rythme de publication est soutenu, avec trois versions entre fin août et début septembre 2026 selon les notes de version, ce qui implique de suivre les changements si vous épinglez une version. Enfin, le projet dépend entièrement des API Google et de leurs quotas : le README ne documente aucun mécanisme de limitation de débit côté serveur, et une instance partagée par plusieurs utilisateurs hérite des quotas du projet Google Cloud sous-jacent.

Face à un serveur MCP écrit sur mesure pour un seul service

L'alternative la plus directe n'est pas un autre produit, c'est un serveur MCP que vous écrivez vous-même pour le seul service dont vous avez besoin. La différence d'approche est nette. Un serveur maison n'expose que les appels que vous avez décidés, avec vos propres noms d'outils et vos propres validations, et il n'y a aucune surface inutilisée à auditer. En échange, vous prenez en charge l'authentification OAuth, le rafraîchissement des jetons, la gestion multi-utilisateur et le transport MCP, c'est-à-dire précisément ce que ce projet a déjà construit. Le choix se résume donc à la surface exposée. Si vous avez besoin de deux ou trois appels sur un seul service, un serveur minimal reste plus simple à raisonner. Si vous voulez couvrir Docs, Sheets, Slides, Forms, Tasks, Contacts et Chat en plus de Gmail, Calendar et Drive, réécrire cette couverture n'a pas de sens, et c'est là que le projet se justifie. Le README mentionne également un CLI complet et un mode Code destiné à des outils comme Claude Code et Codex, ce qui élargit l'usage au-delà du seul protocole MCP.

Licence, maintenance et ce que cela implique

Le projet est sous licence MIT, et le README prend la peine de préciser ce que cela exclut : pas d'open core, pas de source available, pas de CLA, pas de double licence, pas de palier commercial qui verrouillerait des fonctionnalités. Concrètement, l'usage commercial, la modification, l'incorporation dans un produit et la redistribution sont permis, avec la seule exigence d'attribution propre au MIT. Le README indique aussi l'absence de télémétrie intégrée : le serveur n'envoie rien en dehors des API Google, sauf si vous activez vous-même le support OTel optionnel. C'est un argument d'auditabilité vérifiable dans le code, pas une déclaration de conformité. Sur la maintenance, le matériel disponible montre des publications rapprochées et un dépôt non archivé, mais ne donne aucune information sur la durée de support des versions ni sur les migrations entre versions majeures. La chaîne de dépendances est décrite comme majoritairement MIT, Apache 2.0 et BSD, avec un fichier uv.lock pour la figer, ce qui reste le point à examiner si votre processus interne impose une revue des licences tierces.

Conclusion éditoriale

À adopter si vous voulez exposer Workspace à un client MCP avec vos propres identifiants OAuth et un mode lecture seule activable, et si vous acceptez de créer le projet Google Cloud vous-même. À éviter si vous cherchez une intégration sans configuration ou un connecteur maintenu par Google. Avant de déployer en équipe, vérifiez le comportement de validate_file_path() et de ALLOWED_FILE_DIRS dans votre contexte, puis testez le mode stdio sur un seul compte avant de passer en HTTP avec plusieurs utilisateurs.

Sources officielles

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