workspace-mcp を採用する前に確認すべき OAuth 2.1 とツール階層の設計

120以上のツールを1つの MCP サーバーに束ねるという選択

このプロジェクトが解こうとしているのは、AI アシスタントから Google Workspace を操作するたびに、サービスごとの個別連携を用意しなくてはならない問題である。README によれば、Gmail、Calendar、Drive、Docs、Sheets、Slides、Forms、Tasks、Contacts、Chat を含む12の主要サービスが、単一の MCP サーバーの背後に120以上のツールとしてまとめられている。対象読者は、Claude Desktop や Claude Code、ChatGPT の Developer Mode など MCP クライアントを使い、メールや予定表や文書を自然言語で扱いたい開発者およびその所属組織である。README は「the most feature-complete Google Workspace MCP server」と自己記述しているが、これは作者の主張であって第三者の検証結果ではない。判断材料としては、ツール数と対応サービスの広さ、そして後述する認証方式の設計を見るほうが実用的だ。

stdio と streamable HTTP の二経路、そして OAuth 2.1 の置き場所

README が示す構成は、ローカルの stdio と、リモートの streamable HTTP の二通りである。stdio は従来型クライアント向け、HTTP は MCP 仕様の最新版を実装した経路と説明されている。認証は OAuth 2.1 をネイティブに扱い、多人数を想定する。ここで重要なのは、サーバーが Google の API 以外にデータを送らないという設計だ。README の Security 節には「By default, this server sends no data anywhere except Google's APIs」とあり、利用統計やライセンスサーバー、SaaS 依存はなく、OpenTelemetry によるトレースは自分で設定しない限り無効とされている。資格情報は利用者自身の OAuth クライアントと GCP プロジェクトに属し、スコープも自分で制御する。組織全体に配る場合は、外部の認証サーバーやゲートウェイのパススルー認証を使う構成が想定されている。ステートレスモードではディスク書き込みがゼロになるとされ、書き込み不可のコンテナ環境でも動かせる。

ローカルファイル読み取りの境界は validate_file_path() が握る

AI に Workspace を触らせる場合、見落とされやすいのが添付ファイルやローカルファイルへの経路である。README は、ローカルファイル読み取りの既定の対象を管理された添付ディレクトリに限定し、validate_file_path() が .env 系のファイルと、~/.ssh/ や ~/.aws/ のようなホームディレクトリ配下の資格情報置き場をブロックすると説明している。注目すべきは、ALLOWED_FILE_DIRS を広げた場合でもこのブロックが残るという記述だ。設定を緩める操作と、危険なパスを塞ぐ操作が別の層に分かれている。ただし、この関数がどの程度のパス表記の揺れ（シンボリックリンクや相対パスの正規化など）を吸収するのかは README からは読み取れない。ファイル読み取りを業務で使うなら、実際のパス解決の挙動を自分で確認する必要がある。

導入は uv と環境変数、そして Google Cloud 側の準備から

README は導入手順の詳細を本体には置かず、workspacemcp.com の Quick Start と Docs に委ねている。README から確認できる実体は、PyPI の workspace-mcp パッケージ、Python 3.10 以上、uv.lock による依存の固定、そして pyproject.toml に依存ツリーが記載されている点である。設定は環境変数で行い、ALLOWED_FILE_DIRS はファイル読み取りの許可ディレクトリを広げるキーとして名前が挙がっている。デプロイ関連では、リバースプロキシと nginx の設定、送信元（origin）検証、資格情報ストアのバックエンドとして GCS と CMEK、信頼済みゲートウェイの ID 連携、環境変数の完全なリファレンスが Advanced Deployment のページにまとめられている。つまり、README だけで本番構成を組み立てることは想定されておらず、Google Cloud での OAuth クライアント作成とリダイレクト URI の登録を含む手順はサイト側を読む必要がある。

ツール階層と読み取り専用モードが効く場面、効かない場面

README は「three progressive tool tiers」と「read-only mode」に言及する。AI クライアントに渡すツール定義を段階的に絞れること、そして書き込みを封じた状態で動かせることを意味する。これは、まず読み取りだけで様子を見たいチームにとって現実的な安全弁になる。ただし階層の具体的な区分や、どのツールがどの段階に属するかの一覧は README には載っていない。導入時に自分でツール一覧を確認する作業が発生する。もう一点、この種のサーバーに共通する制約として、ツール数そのものがコンテキスト消費とツール選択の精度に影響する。120以上のツールを一度に有効化すれば、モデルが適切なツールを選びにくくなる可能性は設計上避けられない。階層機能はその緩和策として読めるが、README はその効果を数値で示していない。

公式コネクタとの差分は多人数と編集の粒度にある

現実的な比較対象は、Claude や ChatGPT に用意された Google Workspace の組み込み連携、あるいは Google 自身のツールである。README はこれらについて「can't come close to」と表現し、多人数サポートと細かい編集ツールの充実度を差分として挙げている。アプローチの違いは明確で、公式連携が単一アカウントの利用を前提にサービスごとの機能を露出するのに対し、このプロジェクトは自前の OAuth クライアントを軸に、複数ユーザーを1つのサーバーで扱い、12サービスを同じツール体系に揃える。裏返せば、単一アカウントで Gmail を読む程度の用途では、公式連携のほうが設定も運用も軽い。多人数・組織配布・GCP 側の統制といった要件がなければ、このサーバーを選ぶ理由は薄い。

MIT であること、そして維持コストとして何を見るか

ライセンスは MIT で、README は「not 'open core,' not 'source available'」と明言し、デュアルライセンスも商用ティアによる機能制限も CLA もないとしている。商用利用、フォーク、埋め込み、再配布が可能で、条件は帰属表示のみ。依存関係のライセンスは MIT、Apache 2.0、BSD で構成されると記載されている。ここから読み取れる運用上の含意は、ライセンス費用がかからない代わりに、Google Cloud 側の OAuth クライアント、同意画面、スコープ、リダイレクト URI の管理を自分で負うという点だ。リリースは v1.26.0 が2026年9月6日、v1.25.2 が8月28日、v1.25.1 が8月25日と、短い間隔で続いている。活発である一方、固定したバージョンで運用し、uv.lock を基準に更新を検証する姿勢が要る。なお、この記事の筆者は本プロジェクトを実際にインストールして動作を確認しておらず、記述は README とリポジトリのメタデータに基づく。

編集部の結論

自前の GCP プロジェクトと OAuth クライアントを持ち、複数ユーザーに Workspace 操作を AI クライアントから行わせたいチームに向く。逆に、単一アカウントの Gmail 読み取りだけが目的なら、公式のコネクタで足りる可能性が高い。導入前に確認するのは3点。第一に、対象サービスごとに必要な OAuth スコープが Google Cloud の同意画面で許可されるか。第二に、stdio と streamable HTTP のどちらで動かすか、HTTP ならリバースプロキシと送信元検証の設定をどうするか。第三に、ツール階層をどの段階に設定するかで、AI から見える操作の範囲が変わる点である。

公式情報源

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