de en es ja ko zh

google-workspace-unlimited

Name: google-workspace-unlimited
Author: dipseth

by dipseth

Overview Schema Source Related Servers Discussions Admin

Python

🚀 GoogleUnlimited Google Workspace プラットフォーム

docs pypi license privacy terms

google_workspace_fastmcp2 MCP server

GoogleUnlimited は、高度なミドルウェアアーキテクチャを通じて Google Workspace とのシームレスな統合を提供する包括的な MCP フレームワークです。統合された安全な API を使用して、AI アシスタントや MCP クライアントが Gmail、Google Drive、Docs、Sheets、Slides、Calendar、Forms、Chat、Photos、Contacts（People API）の各サービスと連携できるようにします。

他との差別化ポイント：

⚡ Code Mode（デフォルト） — クライアントを90以上のツールスキーマで埋め尽くす代わりに、サーバーは7つの軽量なメタツールを公開します。AI はオンデマンドでツールを発見し、単一のサンドボックス化された execute ブロック内で実際の API 呼び出しを連鎖させます
🚀 ゼロコンフィグ起動 — .env ファイルなしでサーバーが即座に起動します。OAuth は初回使用時に遅延処理されます
🔧 セッション単位のツール制御 — URL ベースのサービスフィルタリングとセッション単位の有効化/無効化により、接続された各クライアントは必要なツールだけを正確に表示できます
🎨 テンプレート＆カード DSL システム — Jinja2 マクロとコンパクトなカード表記法により、生の API データをリッチなメール、ダッシュボード、Google Chat カードに変換します
🧠 セマンティックメモリ — すべてのツール応答が Qdrant に埋め込まれ、後で自然言語で検索できます

📋 目次

Related MCP server: mcp-google-workspace

⚡ クイックインストール手順

GoogleUnlimited とは？

GoogleUnlimited は、Model Context Protocol（MCP）を通じて AI アシスタントに Google Workspace サービスへのアクセスを提供します。9つの Google サービスにわたる 92以上のツールをサポートし、革新的なパフォーマンス向上により、AI ワークフローと Google Workspace アプリケーションのシームレスな統合を実現します。

🛠️ インストール方法

方法1：uvx によるクイックインストール（推奨）

最も簡単な開始方法です。PyPI から直接インストールします：

{
  "mcpServers": {
    "google-workspace-unlimited": {
      "command": "uvx",
      "args": ["google-workspace-unlimited"],
      "disabled": false,
      "timeout": 300
    }
  }
}

⚡ これだけです！ サーバーはデフォルトで stdio モードで実行され、Claude Desktop、Cursor、Roo などの MCP クライアントに最適です。Code Mode が初期状態で有効になっているため、クライアントには90以上のスキーマではなく、7つの軽量メタツールが表示されます。

方法1b：Claude Code プラグイン（サーバー＋スキル）

Claude Code ユーザーは、2つのコマンドで、サーバーと、Claude にカード/メール DSL、コードモード、Qdrant 検索を教えるスキルをインストールできます：

/plugin marketplace add dipseth/google_workspace_fastmcp2
/plugin install google-workspace-unlimited@riversunlimited

詳細は plugins/google-workspace-unlimited を参照してください。

方法2：クローンと開発セットアップ

開発またはカスタマイズの場合：

クローンとセットアップ：

git clone https://github.com/dipseth/google_workspace_fastmcp2.git
cd google_workspace_fastmcp2
uv sync

サーバーを起動：
```
uv run python server.py
```
サーバーは設定が一切不要で即座に起動します。起動時に OAuth 資格情報は必要ありません。認証は、Google サービスに初めてアクセスしたときに遅延処理されます。
準備ができたら認証：
Google Workspace のツールを呼び出すと、サーバーは start_google_auth ツールによる認証を促します。これにより、ブラウザベースの OAuth フローが開きます。完了すると、資格情報はローカルに保存され、セッション間で再利用されます。
OAuth 資格情報を事前設定する場合（任意）、.env ファイルを作成します：
```
cp .env.example .env
```
次に、Google Cloud Console の資格情報を追加します：
```
# Option A: Client ID + Secret
GOOGLE_CLIENT_ID=your-client-id.apps.googleusercontent.com
GOOGLE_CLIENT_SECRET=your-client-secret

# Option B: Downloaded JSON credentials file
GOOGLE_CLIENT_SECRETS_FILE=credentials.json
```
OAuth 資格情報の作成と API の有効化については、Google Cloud Console のセットアップ手順を参照してください。

📚 設定リソース：
🔧 完全設定ガイド - 環境変数と設定の包括的なリファレンス
🤖 Claude.ai 統合ガイド - Claude.ai リモート MCP サーバー利用のセットアップ
🔒 HTTPS セットアップガイド - 安全な接続のための SSL 証明書設定
⚙️ MCP JSON 設定ガイド - 互換性のあるクライアント向けの標準 MCP 設定

📋 環境変数リファレンス

すべての環境変数はオプションです。サーバーは妥当なデフォルト値で起動するため、.env ファイルは不要です。OAuth 資格情報が必要になるのは、start_google_auth で新しい認証フローを開始するときだけです。

Google OAuth（初回認証に必要）：

変数	デフォルト	説明
`GOOGLE_CLIENT_ID`	(empty)	Google Cloud Console の OAuth 2.0 クライアント ID
`GOOGLE_CLIENT_SECRET`	(empty)	OAuth 2.0 クライアントシークレット
`GOOGLE_CLIENT_SECRETS_FILE`	(empty)	代替：ダウンロードした OAuth JSON ファイルへのパス
`OAUTH_REDIRECT_URI`	`http://localhost:8002/oauth2callback`	Google Console のリダイレクト URI と一致する必要があります

初回の OAuth フロー前に、GOOGLE_CLIENT_ID ＋ GOOGLE_CLIENT_SECRET または GOOGLE_CLIENT_SECRETS_FILE のいずれかを指定してください。認証が完了すると資格情報はローカルに保存されるため、これらの変数は以後不要になります。

サーバー：

変数	デフォルト	説明
`SERVER_HOST`	`localhost`	サーバーのバインドアドレス
`SERVER_PORT`	`8002`	サーバーのポート
`ENABLE_HTTPS`	`false`	HTTPS/SSL を有効にする
`SSL_CERT_FILE`	-	SSL 証明書へのパス（HTTPS 有効時に必須）
`SSL_KEY_FILE`	-	SSL 秘密鍵へのパス（HTTPS 有効時に必須）
`LOG_LEVEL`	`INFO`	`DEBUG`, `INFO`, `WARNING`, `ERROR`

セキュリティとセッション：

変数	デフォルト	説明
`CREDENTIAL_STORAGE_MODE`	`FILE_ENCRYPTED`	`FILE_ENCRYPTED`, `FILE_PLAINTEXT`, `MEMORY_ONLY`
`CREDENTIALS_DIR`	`./credentials`	保存された資格情報のディレクトリ
`MCP_API_KEY`	(empty)	サーバー API キー — 暗号にバインドされた資格情報の暗号化（HKDF-SHA256）とユーザーごとのキー生成にも使用されます
`SESSION_TIMEOUT_MINUTES`	`60`	セッションのアイドルタイムアウト
`GMAIL_ALLOW_LIST`	(empty)	カンマ区切りの信頼済みメールアドレス

ツール管理：

変数	デフォルト	説明
`MINIMAL_TOOLS_STARTUP`	`true`	保護された5つのツールのみを有効にして起動
`MINIMAL_STARTUP_SERVICES`	(empty)	起動時に有効にするサービスのカンマ区切りリスト（例：`drive,gmail`）
`ENABLE_CODE_MODE`	`true`	Code Mode（デフォルト）— 完全なツールカタログを7つのメタツール＋サンドボックス化された `execute` に置き換えます。`false` に設定すると従来のカタログを使用
`ENABLE_SKILLS_PROVIDER`	`false`	動的なスキル生成を行う FastMCP SkillsDirectoryProvider を有効にする
`SKILLS_DIRECTORY`	`~/.claude/skills`	生成されたスキルドキュメントのディレクトリ
`RESPONSE_LIMIT_MAX_SIZE`	`500000`	ツール応答の最大サイズ（バイト単位。0 = 無効）
`RESPONSE_LIMIT_TOOLS`	(empty)	制限するツール名のカンマ区切りリスト（空 = すべて）

Qdrant ベクターデータベース：

変数	デフォルト	説明
`QDRANT_URL`	`http://localhost:6333`	Qdrant ベクターデータベースの URL
`QDRANT_KEY`	`NONE`	Qdrant API キー（認証なしの場合は `NONE` を使用）
`QDRANT_AUTO_LAUNCH`	`true`	到達できない場合に Docker 経由で Qdrant を自動起動
`QDRANT_DOCKER_IMAGE`	`qdrant/qdrant:latest`	自動起動用の Docker イメージ
`QDRANT_DOCKER_CONTAINER_NAME`	`mcp-qdrant`	自動起動された Qdrant のコンテナ名

その他：

変数	デフォルト	説明
`MCP_CHAT_WEBHOOK`	(empty)	Google Chat カードツール用のデフォルト Webhook URL
`FASTMCP_CLOUD`	`false`	クラウドデプロイメントモードを有効にする（`MEMORY_WITH_BACKUP` ストレージに自動切り替え）

🔗 クライアント接続

GoogleUnlimited は複数の接続方法をサポートしています。最も一般的な2つの開始方法は次のとおりです：

🎯 クイックセットアップオプション

オプション 1: Cursor IDE (STDIO - コミュニティ検証済み ✅):

{
  "mcpServers": {
    "google-workspace": {
      "command": "uv",
      "args": [
        "--directory", "/path/to/google_workspace_fastmcp2",
        "run", "python", "server.py"
      ],
      "env": {
        "GOOGLE_CLIENT_SECRETS_FILE": "/path/to/client_secrets.json",
        "MCP_TRANSPORT": "stdio"
      }
    }
  }
}

オプション 2: HTTP Streamable (VS Code Roo、Claude Code、Claude Desktop など):

# Start server in HTTP mode
uv run python server.py --transport http --port 8002

基本的な単一接続設定:

{
  "google-workspace": {
    "type": "streamable-http",
    "url": "https://localhost:8002/mcp",
    "disabled": false
  }
}

マルチ接続設定 — URLクエリパラメータを使用して、同じクライアント（または複数のクライアント）を異なるツールセットで同じサーバーに接続します:

{
  "google-email": {
    "type": "streamable-http",
    "url": "https://localhost:8002/mcp?service=gmail"
  },
  "google-chat": {
    "type": "streamable-http",
    "url": "https://localhost:8002/mcp?service=chat"
  },
  "google-productivity": {
    "type": "streamable-http",
    "url": "https://localhost:8002/mcp?service=drive,docs,sheets,slides"
  }
}

各接続は、要求されたサービスのツールのみが有効な、独自の分離されたセッションを取得します。また、?uuid= でセッションIDを固定すると、再接続時に同じセッション状態を再開できます:

{
  "google-workspace": {
    "type": "streamable-http",
    "url": "https://localhost:8002/mcp?uuid=my-workspace&service=gmail,drive,calendar"
  }
}

クエリパラメータの完全なリストについては、URLベースのサービスフィルタリングを参照してください。

🤖 Claude Code と Claude Desktop

Claude Code (CLI) — 公開されているPyPIパッケージを使用した1コマンド:

# Local stdio (recommended): uvx fetches and runs the server on demand
claude mcp add google-workspace -- uvx google-workspace-unlimited

# Or connect to an already-running HTTP server
claude mcp add --transport http google-workspace https://localhost:8002/mcp

Claude Desktop (ローカル開発パス) — claude_desktop_config.json に追加します (設定 → 開発者 → 設定を編集):

{
  "mcpServers": {
    "google-workspace-unlimited": {
      "command": "uvx",
      "args": ["google-workspace-unlimited"]
    }
  }
}

Claude.ai / Claude Desktop (ホステッドコネクタ) — サーバーを公開HTTPSエンドポイント（例: Cloudflare や ngrok トンネル）の背後で実行し、設定 → コネクタ → カスタムコネクタを追加で https://your-domain/mcp URL を追加します。サーバーの OAuth 2.1 + PKCE フローが認証を処理し、https://claude.ai/api/mcp/auth_callback リダイレクトも含みます。詳細な手順については、Claude.ai 統合ガイドを参照してください。

📚 完全な接続ガイド

以下を含む、サポートされているすべてのクライアント向けの詳細なセットアップ手順、トラブルシューティング、構成については:

Claude Code CLI (HTTP & STDIO)
Claude Desktop
VS Code / Roo / GitHub Copilot
Claude.ai with Cloudflare Tunnel
その他...

🔗 完全なクライアント接続ガイド - サポートされているすべてのAIクライアントと開発環境向けの包括的なセットアップ手順、トラブルシューティング、高度な構成

⚡ コードモード（デフォルト）

コードモードはGoogleUnlimitedの主力機能であり、デフォルトでオンです。90以上のツールスキーマを事前に読み込む代わりに（トークン消費が大きい）、MCPクライアントには7つのメタツールだけが表示されます。AIはオンデマンドでツールを発見し、サンドボックス化された単一のPython execute ブロック内で任意の数の実際のAPI呼び出しを連鎖させます。

Meta-Tool	Purpose
`tags`	サービスカテゴリ（Gmail、Drive、Calendarなど）でツールを閲覧する
`search`	BM25ベースのキーワード検索でツール名と説明を横断検索する
`get_schema`	選択したツールの完全なパラメータスキーマを取得する
`semantic_search`	保存済みのツール応答に対する自然言語検索（Qdrantベース）
`fetch_document`	検索結果のポイントIDから保存済みの完全な応答を取得する
`tool_activity`	最近のツール使用パターンとアクティビティを要約する
`execute`	`await call_tool(name, params)` を介して実際のツール呼び出しを連鎖させるサンドボックス化されたPythonブロックを実行する

重要な理由:

💰 大幅なトークン節約 — 90以上ではなく7つのスキーマで、実際に使用するツールの完全なスキーマのみを取得
🔗 多数のラウンドトリップではなく1回で — 検索 → フィルタ → 実行は、クライアントのラウンドトリップの連鎖ではなく、単一の execute ブロック内で行われます
🧰 バッテリー同梱のサンドボックス — 40以上の組み込みヘルパー（now()、days_ago()、to_json()、re_find()、gather_tools() など）が、インポートなしで日付、JSON、URL、正規表現、数学、バッチ呼び出しをカバーします

# One execute block: find a Drive file, then email its link
files = await call_tool("search_drive_files", {"query": "Q4 report"})
link = files["files"][0]["webViewLink"]
result = await call_tool("send_gmail_message", {
    "to": "manager@company.com",
    "subject": "Q4 Report",
    "body": "Here's the Q4 report: " + link,
})
return result

従来のカタログがお好みですか？ オプトアウトすると、すべてのツールがクライアントに直接公開されます:

ENABLE_CODE_MODE=false   # expose the full 90+ tool catalog instead

コードモードと従来のカタログは相互排他的です — コードモードが有効な場合、直接のツール呼び出しは検索 + execute パターンに置き換えられます。ディスカバリツールは、セッションレベルのフィルタリングに関係なく、常に完全なカタログを参照します。

🎯 サービス機能

GoogleUnlimitedは、90以上の専門ツールを備えた10のGoogle Workspaceサービスをサポートしています:

Service	Icon	Tools	Key Features	Documentation
Gmail	📧	14	送信、返信、ラベル、フィルタ、検索、許可リスト	`api-reference/gmail/`
Drive	📁	9	アップロード、ダウンロード、共有、Officeドキュメント、ファイル管理	`api-reference/drive/`
Docs	📄	4	作成、編集、フォーマット、バッチ操作	`api-reference/docs/`
Sheets	📊	7	読み取り、書き込み、数式、フォーマット	`api-reference/sheets/`
Slides	🎯	5	プレゼンテーション、テンプレート、エクスポート	`api-reference/slides/`
Calendar	📅	9	イベント、スケジュール、参加者、タイムゾーン	`api-reference/calendar/`
Forms	📝	8	作成、回答、検証、公開	`api-reference/forms/`
Chat	💬	24	メッセージング、カード、スペース、ウェブフック、ユニファイドカード	`api-reference/chat/`
Photos	📷	12	アルバム、アップロード、検索、メタデータ、スマート検索	`api-reference/photos/`
People	👤	4	名前→メール検索（連絡先 + 組織ディレクトリ）、連絡先ラベル	`people/`

📚 APIドキュメントリソース:
🔗 完全なAPIリファレンス - 10サービスにわたる92以上の全ツールの包括的なドキュメント
📧 Gmail APIガイド - メール管理、ラベル、フィルタ、検索操作
📁 Drive APIガイド - ファイル操作、共有、Officeドキュメント処理
📊 Sheets APIガイド - スプレッドシートのデータ操作とフォーマット
📅 Calendar APIガイド - イベントスケジュールとタイムゾーン管理

🧠 ミドルウェアアーキテクチャ

GoogleUnlimitedは、シームレスなサービス統合、インテリジェントなリソース管理、強力なテンプレート機能を提供するミドルウェアアーキテクチャを使用しています。

Middleware Architecture

🔧 コアミドルウェアコンポーネント

🏷️ TagBasedResourceMiddleware: URIパターン（service://gmail/messages、user://current/email）を使用したインテリジェントなリソース発見
🧠 QdrantUnifiedMiddleware: ベクトル埋め込みによる全ツール応答にわたるAI駆動のセマンティック検索
🎨 TemplateMiddleware: 美しく構造化された出力フォーマットのための高度なJinja2テンプレートシステム

✨ アーキテクチャの利点

🔄 統合リソースアクセス: API呼び出しなしでサービスデータへのURIベースのアクセス
🧠 セマンティックインテリジェンス: 保存されたすべての応答にわたる自然言語検索
🎨 視覚的優秀性: AIが最適に消費できる、一貫性のある美しい出力フォーマット
💰 トークン効率: テンプレートマクロが構造化データレンダリングによりトークン使用量を60〜80%削減
⚡ パフォーマンス: インテリジェントキャッシュにより従来のアプローチより30倍高速

📚 ミドルウェアドキュメントリソース:
📖 ミドルウェアアーキテクチャガイド - 完全なミドルウェアシステムのドキュメントと実装詳細
🏷️ TagBasedResourceMiddleware - URIパターンのリソース発見と管理
🧠 QdrantUnifiedMiddleware - AI駆動のセマンティック検索とベクトル埋め込み
🎨 TemplateMiddleware - 出力フォーマットのための高度なJinja2テンプレートシステム
🔧 SessionToolFilteringMiddleware - セッションごとのツール有効/無効管理

🚀 最小ツール起動

デフォルトでは、GoogleUnlimitedは最適なパフォーマンスとセキュリティのために、保護された5つのツールのみを有効にして起動します。これにより、クライアントは必要なツールだけを有効にできます。

保護されたツール（常に利用可能）:

manage_tools - ツールをグローバルまたはセッションごとに有効/無効にする
manage_tools_by_analytics - アナリティクスベースのツール管理
health_check - サーバーのヘルスと構成ステータス
start_google_auth - OAuth認証を開始する
check_drive_auth - 認証ステータスを確認する

構成:

# Default: Start with minimal tools (only 5 protected tools)
MINIMAL_TOOLS_STARTUP=true

# Optional: Pre-enable specific services at startup
MINIMAL_STARTUP_SERVICES=drive,gmail,calendar

# Disable minimal startup (enable all 92+ tools immediately)
MINIMAL_TOOLS_STARTUP=false

実行時のツール有効化:

# Enable all tools globally
manage_tools(action="enable_all")

# Enable specific tools
manage_tools(action="enable", tool_names=["search_drive_files", "list_gmail_labels"])

# List all registered tools (shows enabled/disabled status)
manage_tools(action="list")

🔧 セッションスコープのツール管理

GoogleUnlimitedはセッションごとのツール有効/無効機能をサポートしており、他の接続中のクライアントに影響を与えることなく、異なるMCPクライアントが異なるツール利用状況を持つことができます。

主な機能:

セッション分離: 他のセッションに影響を与えずに、1つのクライアントセッションのツールを無効にする
非侵襲: セッションスコープの操作はグローバルツールレジストリを変更しない
保護されたツール: コア管理ツール（manage_tools、health_check など）は常に利用可能
ミドルウェアベース: プロトコルレベルのフィルタリングに SessionToolFilteringMiddleware を使用

使用例:

# Disable tools for this session only (other clients unaffected)
manage_tools(action="disable", tool_names=["send_gmail_message"], scope="session")

# Disable all except specific tools for this session
manage_tools(action="disable_all_except", tool_names=["search_drive_files", "list_events"], scope="session")

# Re-enable all tools for this session
manage_tools(action="enable_all", scope="session")

# Global operations (original behavior, affects all clients)
manage_tools(action="disable", tool_names=["send_gmail_message"], scope="global")

レスポンス構造:

{
  "success": true,
  "action": "disable_all_except",
  "scope": "session",
  "enabledCount": 94,
  "disabledCount": 0,
  "toolsAffected": ["tool1", "tool2", "..."],
  "sessionState": {
    "sessionId": "f725be09...",
    "sessionAvailable": true,
    "sessionDisabledTools": ["tool1", "tool2"],
    "sessionDisabledCount": 89
  },
  "message": "Kept 5 tools, disabled 89 tools for this session"
}

📚 スキルプロバイダー

ENABLE_SKILLS_PROVIDER=true で有効にすると、GoogleUnlimitedはModuleWrapperインスタンスからスキルドキュメントを生成し、FastMCPの SkillsDirectoryProvider を介して提供します。スキルは、LLMが複雑なマルチステップタスクのために参照できる構造化された知識を提供します。

現在サポートされているモジュール:

card_framework → gchat-cards スキル (Google ChatカードDSLリファレンス、コンポーネント階層、例)

構成:

ENABLE_SKILLS_PROVIDER=true     # Enable skill generation
SKILLS_DIRECTORY=~/.claude/skills  # Output directory (default)

スキルは起動のたびに自動再生成され、FastMCPスキルシステムを介してすぐに利用可能になります。

🖥️ ツール管理ダッシュボード

GoogleUnlimitedには、MCP Appsの ui:// リソーススキームを介して提供される組み込みのツール管理ダッシュボードが含まれています。これは、セッション全体のツール利用状況を監視および管理するための視覚的インターフェースを提供します。

Tool Management Dashboard

機能:

サービス別ツールビュー — Googleサービス（Gmail、Drive、Sheetsなど）ごとに整理されたツールと件数
セッション状態の可視性 — 有効、無効、またはセッション無効のツールをひと目で確認
フィルタチップ — サービスですばやくフィルタリングして関連ツールに集中
ライブデータ — DashboardCacheMiddleware によって駆動され、list-tool結果をキャッシュして ui://data-dashboard リソースへ即座にアクセス

ダッシュボードは wire_dashboard_to_list_tools() を介してすべてのlistツールに自動的に配線されます — ツールごとの設定は不要です。

🔗 URLベースのサービスフィルタリング（HTTPトランスポート）

HTTP/SSEトランスポートを使用する場合、URLクエリパラメータを介してサービスごとにツールを直接フィルタリングできます - コードは不要です:

# Enable only Gmail tools
http://localhost:8002/mcp?service=gmail

# Enable Gmail + Drive + Calendar
http://localhost:8002/mcp?service=gmail,drive,calendar

# Resume a previous session
http://localhost:8002/mcp?uuid=your-session-id

# Resume session with specific services
http://localhost:8002/mcp?uuid=abc123&service=gmail,drive

# Disable minimal startup (enable all tools)
http://localhost:8002/mcp?minimal=false

利用可能なURLパラメータ:

パラメータ	例	説明
`service` または `services`	`?service=gmail,drive`	有効にするサービスのカンマ区切りリスト
`uuid`	`?uuid=abc123`	ID で以前のセッションを再開
`minimal`	`?minimal=false`	最小限の起動モードを上書き

利用可能なサービス: gmail、drive、calendar、docs、sheets、slides、photos、chat、forms、people

📚 セッションツール管理リソース:
🔧 SessionToolFilteringMiddleware ガイド - セッションごとのツール管理の完全なドキュメント

🎨 テンプレートシステム

GoogleUnlimited は強力な Jinja2 テンプレートマクロ を備えており、生の Google Workspace データを視覚的に美しく、AI に最適化された形式に変換します。

🎯 利用可能なテンプレートマクロ

テンプレートファイル	マクロ	目的	主な機能
`email_card.j2`	`render_gmail_labels_chips()`	Gmail ラベルの可視化	インタラクティブなチップ、未読数、Gmail への直接リンク
`calendar_dashboard.j2`	`render_calendar_dashboard()`	カレンダー＆イベントダッシュボード	プライマリ/共有カレンダー、今後のイベント、ダークテーマ
`dynamic_macro.j2`	`render_calendar_events_dashboard()`	カレンダーイベントダッシュボード	イベントカード、時刻/場所の詳細、クリック可能なリンク、ダークテーマ
`document_templates.j2`	`generate_report_doc()`	プロフェッショナルなレポート	メトリクス、テーブル、チャート、会社ブランディング
`colorfuL_email.j2`	`render_beautiful_email3()`	リッチな HTML メール	複数の署名、グラデーション、レスポンシブデザイン

💡 テンプレートマクロの例

Gmail ラベルの可視化 - ラベルリストを美しいインタラクティブなチップに変換:

{{ render_gmail_labels_chips( service://gmail/labels , 'Label summary for: ' + user://current/email ) }}

カレンダーダッシュボード - 包括的なカレンダー概要を作成:

{{ render_calendar_dashboard( service://calendar/calendars, service://calendar/events, 'My Calendar Overview' ) }}

カレンダーイベントダッシュボード - カレンダーイベントを美しくインタラクティブなイベントカードに変換:

{{ render_calendar_events_dashboard( service://calendar/events , 'Upcoming Events for: ' + user://current/email.email ) }}

Calendar Events Dashboard Example

このマクロは、見事なダークテーマのダッシュボードを作成します:

📅 インタラクティブなイベントカード: 各イベントは Google カレンダーで開くクリック可能なカードとしてレンダリングされます
🕐 スマートな時刻表示: 終日イベントと時刻指定イベントをタイムゾーン対応で自動的にフォーマット
📍 場所の統合: 会議の場所とバーチャル会議リンクを表示
👥 参加者情報: 参加者数と参加者の詳細を表示
✅ ステータスインジケーター: 色分けされたステータス（確定、仮予定、キャンセル）と視覚的なフィードバック
📱 レスポンシブデザイン: タッチ操作に最適化されたモバイル対応レイアウト
🎨 ダークテーマのスタイリング: グラデーション背景とホバーエフェクトを備えたプロフェッショナルな外観

プロフェッショナルなドキュメント - メトリクスとチャートを含むレポートを生成:

{{ generate_report_doc(
    report_title='Q4 Performance Report',
    metrics=[{'value': '$1.2M', 'label': 'Revenue', 'change': 15}],
    company_name='Your Company'
) }}

🔍 マクロの発見と動的作成

テンプレートリソースシステムを使用して、利用可能なすべてのマクロを探索:

# Access the template://macros resource to discover all available macros
macros = await access_resource("template://macros")
# Returns comprehensive macro information with usage examples

# Access specific macro details
macro_details = await access_resource("template://macros/render_gmail_labels_chips")

🎯 動的マクロ作成

create_template_macro ツールを使用して、実行時にカスタムマクロを作成:

# Create a new macro dynamically
await create_template_macro(
    macro_name="render_task_status_badge",
    macro_content='''
    {% macro render_task_status_badge(status, size='small') %}
    {% if status == 'completed' %}
    <span class="status-badge status-completed {{ size }}">✅ Complete</span>
    {% elif status == 'in_progress' %}
    <span class="status-badge status-in-progress {{ size }}">🔄 In Progress</span>
    {% else %}
    <span class="status-badge status-pending {{ size }}">⏳ {{ status|title }}</span>
    {% endif %}
    {% endmacro %}
    ''',
    description="Renders visual status badges for task states with appropriate icons",
    usage_example="{{ render_task_status_badge('completed', 'large') }}",
    persist_to_file=True
)

# Immediately use the newly created macro
await send_gmail_message(
    html_body="Task Status: {{ render_task_status_badge('completed', 'large') }}"
)

DSL 駆動のマクロ — 動的マクロは Google Chat カード DSL 表記を埋め込んで、リッチで構造化されたカードを生成することもできます。DSL シンボルがカードレイアウトを定義し、Jinja2 が動的コンテンツを処理します:

{# workspace_dashboard.j2 — a dynamic macro that outputs a Google Chat card #}
{% macro workspace_dashboard(user_email, stats=None, quick_actions=None) %}
{% set username = user_email.split('@')[0] if user_email else 'User' %}
{% set default_stats = stats or [
    {'label': 'Emails', 'value': '12 unread'},
    {'label': 'Calendar', 'value': '3 meetings today'},
    {'label': 'Tasks', 'value': '5 pending'}
] %}

§[δ×3, ℊ[ǵ×4], §[δ×2, Ƀ[ᵬ×3]]]

Welcome back, {{ username | title }}!

Your Workspace Overview:
{% for stat in default_stats %}
- {{ stat.label }}: {{ stat.value }}
{% endfor %}

Actions:
- Button: Open Gmail → https://mail.google.com
- Button: Open Calendar → https://calendar.google.com
- Button: Open Drive → https://drive.google.com
{% endmacro %}

DSL 行 §[δ×3, ℊ[ǵ×4], §[δ×2, Ƀ[ᵬ×3]]] はカード構造を定義します: 3 つの DecoratedText ウィジェットを持つセクション、4 つのアイテムを持つグリッド、2 つの DecoratedText ウィジェットと 3 つのボタンを持つ ButtonList を含むネストされたセクション。Jinja2 テンプレートが動的にコンテンツを埋め込みます — そして templates/dynamic/ に永続化されるため、send_dynamic_card や他のツールですぐに利用できます。

主な機能:

⚡ 即時利用可能性: マクロは作成後すぐに利用可能
🎯 リソース統合: template://macros/macro_name 経由で自動的に利用可能
💾 オプションの永続化: マクロをディスクに保存して恒久的に利用可能に
🔄 テンプレート処理: 完全な Jinja2 構文検証とエラーハンドリング
💬 DSL 統合: マクロはリッチな Google Chat カード用のカード DSL 表記を出力可能

🚀 実世界での使用例

テンプレートはツール呼び出しで直接使用でき、美しく構造化された出力を実現します:

# Send a beautiful email with calendar dashboard
await send_gmail_message(
    to="manager@company.com",
    subject="Weekly Schedule Update",
    html_body="{{ render_calendar_events_dashboard( service://calendar/events, 'My upcoming events') }}",
    content_type="mixed"
)

# Generate and send a professional report
await create_doc(
    title="Q4 Performance Report",
    content="{{ generate_report_doc( report_title='Quarterly Results', company_name='GoogleUnlimited' ) }}"
)

📚 テンプレートシステムリソース:
🎨 テンプレートディレクトリ - Jinja2 テンプレートとマクロの完全なコレクション
💌 美しいメールテンプレート - リッチな HTML メールのスタイリングとテーマ
🏷️ Gmail ラベルカード - チップによるインタラクティブなラベル可視化
📅 カレンダーダッシュボード - イベントタイムラインとスケジュール表示
📄 ドキュメントテンプレート - 構造化されたドキュメントフォーマット

🗂️ リソースディスカバリー

GoogleUnlimited は強力な MCP リソースシステム を提供し、インテリジェントな URI パターンを通じて API 呼び出しなしで電光石火のデータアクセスを実現します。

Resource Discovery

🎯 リソース URI パターン

パターン	目的	例	戻り値
`user://profile/{email}`	ユーザー認証ステータス	`user://profile/john@gmail.com`	プロフィール + 認証状態
`service://{service}/lists`	利用可能なサービスリスト	`service://gmail/lists`	[フィルター、ラベル]
`service://{service}/{list_type}`	リスト内のすべてのアイテム	`service://gmail/labels`	すべての Gmail ラベル
`service://{service}/{list_type}/{id}`	特定アイテムの詳細	`service://gmail/labels/INBOX`	INBOX ラベルの詳細
`recent://{service}`	最近のアイテム	`recent://drive`	最近の Drive ファイル
`qdrant://search/{query}`	セマンティック検索	`qdrant://search/gmail errors`	関連する応答

🏗️ 主要なリソースファイル

resources/user_resources.py: 認証、プロフィール、セッション管理（1,812 行）
resources/service_list_resources.py: TagBasedResourceMiddleware によるサービスディスカバリー（446 行）
middleware/qdrant_core/resources.py: AI を活用した検索と分析（319 行）

⚡ 電光石火のアクセス

# Instant Gmail labels (no API call needed)
labels = await access_resource("service://gmail/labels")

# Current user info from session
user = await access_resource("user://current/email")

# Semantic search across all tool responses
results = await access_resource("qdrant://search/gmail errors today")

# Recent calendar events
events = await access_resource("recent://calendar")

📚 リソースシステムのドキュメント:
🗂️ ユーザーリソース - 認証、プロフィール、セッション管理（1,812 行）
🏷️ サービスリストリソース - TagBasedResourceMiddleware によるサービスディスカバリー（446 行）
🧠 Qdrant コアリソース - AI を活用した検索と分析（319 行）
📋 リソースパターンガイド - 完全な URI パターンリファレンスと使用例

🧪 テストフレームワーク

GoogleUnlimited には、LLM が実際に体験するのとまったく同じ方法で MCP の使用を検証する クライアントテスト を含む包括的なテストが含まれています。さらに追加のテストスイートもあります。559 件のテストが 100% の合格率で成功しています。

🎯 クライアントテストの焦点

Testing Framework

クライアントテスト は最も重要なコンポーネントです。実際のリソース統合と、92 以上のツール と 9 つの Google サービス にわたる標準化されたパターンを使用して、MCP 操作の決定的なテストを提供します。これらのテストは、明示的なメール認証とミドルウェアインジェクションパターンの両方を検証します。

🚀 クイックテストコマンド

# 🧪 Run all client tests (primary test suite)
uv run pytest tests/client/ -v

# 📧 Test specific service
uv run pytest tests/client/ -k "gmail" -v

# 🔐 Authentication required tests
uv run pytest tests/client/ -m "auth_required" -v

🔬 実際のリソース ID 統合

テストフレームワークは、現実的なテストのためにサービスリソースから 実際の ID を取得します:

# Available fixtures for real resource testing
real_gmail_message_id      # From service://gmail/messages
real_drive_document_id     # From service://drive/items
real_calendar_event_id     # From service://calendar/events
real_photos_album_id       # From service://photos/albums
real_forms_form_id         # From service://forms/forms
real_chat_space_id         # From service://chat/spaces

🔄 CI/CD パイプライン

GitHub Actions による自動テストと公開:

CI ワークフロー: すべての PR と main へのプッシュ時に実行
- Python 3.11 & 3.12 マトリックステスト
- ruff check によるリンティングと ruff format によるフォーマット
- 完全なテストスイートの実行
TestPyPI 公開: テスト用の自動パッケージ公開

📚 テストリソース:
📋 クライアントテストフレームワークガイド - 完全なクライアントテストのドキュメントとパターン
🧪 クライアントテストディレクトリ - 決定的な MCP 検証のための実際のリソース統合テスト
🤖 MCP クライアント統合 - MCP クライアントのパターンと使用法の詳細
🔐 認証パターン - メールとミドルウェアインジェクションの検証テスト

🔒 セキュリティと認証

GoogleUnlimited は、OAuth 2.1 + PKCE、高度なセッション管理、包括的な監査機能を備えた エンタープライズグレードのセキュリティ を実装しています。

Security Architecture

🛡️ 認証フロー

🌐 MCP Inspector OAuth: 動的クライアント登録に対応した MCP 仕様準拠
🖥️ ダイレクトサーバー OAuth: 直接アクセスのための Web ベース認証
🔧 開発用 JWT: 生成されたトークンによるテストモード
📁 拡張ファイル資格情報: 暗号化オプション付きの永続ストレージ
🔑 カスタム OAuth クライアント: 自動フォールバック付きで独自の OAuth 資格情報を使用
🪪 ユーザーごとの API キー: OAuth 完了時に資格情報の分離を備えて生成される個別キー

✨ セキュリティ機能

🔐 OAuth 2.1 + PKCE: 鍵交換の証明による最新の認証（パブリッククライアントをサポート）
🔑 ユーザーごとの API キー: ハッシュのみの保存とタイミングセーフなルックアップを備えた、ユーザーごとの一意で失効可能なキー
🛡️ 資格情報の分離: 認証由来に基づくアクセス制御により、ユーザー間の資格情報の継承を防止
🔗 アカウントリンク: ユーザーごとのキーアクセスのための複数アカウント対応の双方向アカウントリンク
🔒 暗号バウンド暗号化: MCP_API_KEY にバインドされた HKDF-SHA256 派生暗号化キー
🔒 セッション分離: データ漏洩を防ぐマルチテナントサポート
🏷️ 27 以上の API スコープ: すべてのサービスにわたるきめ細かな権限管理
📊 監査ログ: 認証由来を含む完全なセキュリティイベント追跡
🔐 AES-256 暗号化: レガシーキー移行サポート付きの資格情報ストレージ
🔄 3 層フォールバック: サーバー再起動をまたぐ堅牢な資格情報の永続化（State Map → UnifiedSession → Context Storage）
🧹 機密データの除去: 保存前に Qdrant 埋め込みから認証メタデータを削除

⚙️ セキュリティ設定

# 🔒 Security settings in .env
CREDENTIAL_STORAGE_MODE=FILE_ENCRYPTED
SESSION_SECRET_KEY=your-secret-key
SESSION_TIMEOUT_MINUTES=30
ENABLE_AUDIT_LOGGING=true
GMAIL_ALLOW_LIST=trusted@example.com

📚 セキュリティドキュメントリソース:
🛡️ 統合 OAuth アーキテクチャ - 完全なセキュリティアーキテクチャと認証設計
🔐 OAuth 2.1 + PKCE 実装 - 鍵交換の証明による最新の認証
🏠 セッション管理ガイド - マルチテナントサポートとセッション分離
🔒 暗号化とストレージ - AES-256 資格情報の暗号化とマシン固有のキー
📊 監査ログシステム - 完全なセキュリティイベントの追跡と監視

🚀 Google Workspace 統合に革命を起こす準備はできましたか？

📚 ドキュメント • 🔧 設定 • 🎯 API リファレンス • 🧪 テスト

Available Tools

7 tools

executeExecuteA

Run sandboxed Python that calls this server's Google Workspace tools via await call_tool(tool_name, params), chaining calls in one block. Use when: you know which tools to call. To find tool names first use search or tags; for exact parameters use get_schema; to look up past results instead, use semantic_search. Behavior: each call_tool runs the real tool immediately — sends, edits, and deletes take effect; there is no dry-run. Use return to produce output; prefer returning the final answer from a single block. Only call_tool(tool_name: str, params: dict) -> Any is available in scope. Unknown tool names raise NotFoundError; disallowed syntax raises SandboxError.

SANDBOX RESTRICTIONS — these produce SandboxError, avoid them:

sorted_(items, key=lambda x: x['k']) → lambda args fail; use builtins like key=len or sort manually
import only covers a small stdlib subset (e.g. json); no third-party modules — prefer the built-in helpers listed below

Built-in helpers (import is not available — use these instead):

now(tz_offset=0) → current datetime string (UTC by default)
today(tz_offset=0) → current date 'YYYY-MM-DD' (UTC by default)
days_ago(n, tz_offset=0) → ISO datetime string N days ago
hours_ago(n, tz_offset=0) → ISO datetime string N hours ago
format_date(iso_str, fmt='%Y-%m-%d %H:%M') → formatted date
parse_date(iso_str) → normalized ISO datetime
timestamp() → current unix timestamp (int)
to_json(obj, indent=None) → JSON string
from_json(s) → parsed object
url_encode(s) → URL-encoded string
url_decode(s) → URL-decoded string
url_join(base, *parts) → joined URL path
query_string(params) → URL query string from dict
re_find(pattern, text) → list of matches
re_match(pattern, text) → bool
re_sub(pattern, repl, text) → substituted string
truncate(text, n=80) → truncated with '...'
dedent(text) → remove common leading whitespace
wrap_text(text, width=72) → word-wrap to width
pad_left(s, width, char=' ') → right-justify / zero-pad
pad_right(s, width, char=' ') → left-justify
join(items, sep=', ') → joined string
html_escape(s) → HTML-safe string
sqrt(n), ceil(n), floor(n) → math
round_(n, digits=2), abs_(), min_(), max_(), sum_() → math
sorted_(items, key=None, reverse=False) → sorted list
unique(items) → deduplicated list (preserves order)
flatten(lists) → flat list from nested lists
counter(items) → dict of {item: count}
chunk(items, size) → list of chunks
zip_(*iterables) → zipped as list of lists
dict_get(d, 'a.b.c', default=None) → nested dict access
md5(s), sha256(s) → hash hex digests
gather_tools(calls) → run multiple tool calls sequentially; calls is a list of [tool_name, params] pairs, returns list of results (assign to variable, then index: r = await gather_tools([...]); a, b = r[0], r[1])
sleep(seconds) → async sleep

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Python async code to execute tool calls via call_tool(name, arguments)

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description carries the full burden, and it does so thoroughly. It discloses that each call_tool runs the real tool immediately with sends/edits/deletes taking effect and no dry-run, plus sandbox restrictions, error types, and disallowed syntax. This is substantial behavioral context beyond what the schema provides.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured with clear sections: use-when, behavior, sandbox restrictions, and built-in helpers. Core usage and side effects are front-loaded, and every block provides actionable information rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that annotations and an output schema are absent, the description is remarkably complete. It covers selection criteria, invocation syntax, execution environment, side effects, error modes, restrictions, and helper APIs, so an agent can use this tool without needing additional documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes the single `code` parameter at 100% coverage, but the description adds far more semantic value: valid async syntax, `call_tool` signature, use of `return`, restrictions on `import`, sandbox errors, and a full list of available built-in helpers. This gives the agent everything needed to construct valid code.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a precise verb and resource: running sandboxed Python that calls this server's Google Workspace tools via `await call_tool(tool_name, params)` and chaining calls in one block. It also distinguishes itself clearly from discovery/search siblings by framing this as the execution step once tool names are known.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit 'Use when' condition: when you know which tools to call. It also names alternatives for other cases: `search` or `tags` for finding tool names, `get_schema` for exact parameters, and `semantic_search` for past results, providing clear routing to sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

fetch_documentFetch DocumentA

Preview one stored tool response by its Qdrant point ID.

Use when: inspecting a hit returned by semantic_search. To find point IDs in the first place, use semantic_search; for the full untruncated content, call the fetch tool inside an execute block.

Behavior: read-only. Returns: tool name, service, timestamp, user, argument count, and the first 500 characters of stored content. Errors: 'Document not found' for unknown or expired point IDs.

ParametersJSON Schema

Name	Required	Description	Default
`point_id`	Yes	Qdrant point ID (UUID) from a search result
`user_google_email`	No	User's Google email (auto-injected by middleware)

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully carries the behavioral disclosure burden. It states 'Behavior: read-only', describes the exact return fields including the 500-character truncation, and documents the error condition 'Document not found' for unknown or expired IDs. This is unusually transparent for a tool description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, well-organized with labeled sections, and front-loads the core purpose. Every sentence adds useful content, and there is no redundant repetition of schema or annotation details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description enumerates the return fields and truncation behavior, making the tool's output predictable. It also covers errors, read-only behavior, and usage context, making the description complete for an agent to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters clearly. The description adds context around the point_id's role in previewing a stored response, but does not need to add more because the parameter semantics are fully captured in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Preview one stored tool response') and identifies the resource by 'Qdrant point ID', clearly distinguishing this from sibling search and execute tools. It also explicitly indicates what it is not for, such as full untruncated content, which further sharpens purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Use when' section directly instructs to use this tool when inspecting a hit from semantic_search, and explicitly points to alternatives for finding point IDs and retrieving full content. This is exemplary routing guidance that leaves no ambiguity about when to use this tool versus siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_schemaGet SchemaA

Get parameter schemas for named tools before calling them via execute. Use when: you already have tool names (from search or tags) and need exact parameters. Not for discovery — use search for that. Returns: per-tool parameter markdown ('detailed', default), names + descriptions ('brief'), or full JSON schemas ('full'); unknown names are reported under 'Tools not found'.

ParametersJSON Schema

Name	Required	Description	Default
`tools`	Yes	List of tool names to get schemas for
`detail`	No	'brief' for names and descriptions, 'detailed' for parameter schemas as markdown, 'full' for complete JSON schemas	detailed

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses the output formats for each detail mode and the unknown-name handling behavior ('reported under Tools not found'). It does not explicitly state side effects, but the read-only nature is strongly implied by the verb 'get' and the schema-fetching purpose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, front-loaded with the core purpose, and uses clear logical sections ('Use when', 'Not for discovery', 'Returns'). Every sentence earns its place without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete for a tool with no output schema and no annotations. It covers the main purpose, usage conditions, output formats, defaults, and error handling for unknown tool names. No critical operational gap remains for an agent deciding how to call this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema coverage is 100%, so the baseline is 3. The description mostly restates what the schema already says about 'detail' and 'tools'; it adds minor value with 'per-tool parameter markdown' and unknown-name behavior, but does not substantially deepen parameter understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Get parameter schemas for named tools before calling them via execute.' It clearly differentiates from the sibling search tool by framing this as a pre-execute lookup step, not a discovery mechanism.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool ('when you already have tool names... and need exact parameters'), when not to use it ('Not for discovery'), and names the alternative ('use search for that'). This gives an agent unambiguous routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

searchSearchA

Find this server's Google Workspace tools by keyword (BM25 over names, descriptions, and tags). Use when: you don't know the exact tool name yet. To browse by category use tags; once you have names, use get_schema for parameters, then execute to call them. To search past results rather than tools, use semantic_search. Returns: matching tools as names + descriptions ('brief', default), parameter markdown ('detailed'), or complete JSON definitions ('full'). An empty result means no keyword match — retry with different terms.

ParametersJSON Schema

Name	Required	Description	Default
`tags`	No	Filter to tools with any of these tags before searching
`limit`	No	Maximum number of results to return
`query`	Yes	Search query to find available tools
`detail`	No	'brief' for names and descriptions, 'detailed' for parameter schemas as markdown, 'full' for complete JSON schemas	brief

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does this well by revealing the BM25 ranking mechanism, the three return detail modes, the default 'brief' mode, and the meaning of an empty result ('no keyword match — retry with different terms'). This gives an agent a clear behavioral model beyond what the schema states.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured. The primary purpose is stated first, followed by explicit usage guidance, sibling routing, and return behavior. Every sentence earns its place; there is no filler or repetition of schema details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with no annotations and no output schema, the description is thorough: it explains what is searched, when to use it, how to route to alternatives, what the return values look like in each detail mode, and how to interpret empty results. Nothing critical is missing for safe and correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters clearly. The description adds a little context around the detail parameter's output modes, but most of what it says about parameters mirrors the schema. This meets the baseline but does not go substantially beyond it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource: 'Find this server's Google Workspace tools by keyword,' and specifies the search mechanism (BM25 over names, descriptions, and tags). It also distinguishes the tool from siblings like tags and semantic_search, so an agent can immediately tell what this tool is for.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use guidance: 'Use when: you don't know the exact tool name yet.' It also names alternatives and the conditions for choosing them, such as using tags to browse by category, get_schema for parameters, execute to call, and semantic_search for past results. This is exemplary routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

semantic_searchSemantic SearchA

Search the Qdrant vector store of this server's past tool responses and card templates.

Use when: looking up previous results, usage history, or analytics ('service:gmail last week', 'tool:search recent', 'overview'). For discovering tools to call, use search; to preview one stored document, pass its point ID to fetch_document.

Modes: semantic text similarity; service/tool history queries; analytics ('overview', 'usage stats'); filter_dsl for structured filters; positive/negative point IDs for recommendation; query_dsl for fusion/discover/order-by; prefetch_dsl for multi-stage retrieval.

Behavior: read-only against the local Qdrant instance; no Google APIs are called. Returns: scored rows 'score service/tool timestamp id:'. Errors: 'Search failed' when Qdrant is unreachable; 'No results' when nothing clears score_threshold (default 0.3 — lower it to widen the net).

DSL filter symbols: D_5=DatetimeRange, ʄ=FieldCondition, ƒ=Filter, F_6=FilterSelector, ℏ=HasIdCondition, I_2=IsEmptyCondition, I_0=IsNullCondition, ɱ=MatchAny, ṁ=MatchText, M_0=MatchTextAny, ☆=MatchValue, ř=Range Query-DSL symbols: Å=AcornSearchParams, C_14=ContextExamplePair, ¢=ContextPair, C_0=ContextQuery, D_6=DiscoverInput, D_2=DiscoverQuery, D_4=DiscoverRequest, D_21=DiscoverRequestBatch, ℱ=Fusion, φ=FusionQuery, ø=OrderBy, ɵ=OrderByQuery, ¶=Prefetch, ʔ=QuantizationSearchParams, R_12=RecommendGroupsRequest, R_2=RecommendInput, R_4=RecommendQuery, R_5=RecommendRequest, R_18=RecommendRequestBatch, R_10=RecommendStrategy, ♦=SearchParams Example: ƒ{must=[ʄ{key="tool_name", match=☆{value="send_dynamic_card"}}]} MatchAny: ƒ{must=[ʄ{key="tool_name", match=ɱ{any=["tool_a", "tool_b"]}}]}

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum results to return
`query`	Yes	Search query — natural language, 'service:gmail recent', 'overview', 'id:<point_id>', or semantic text when filter_dsl is set
`dry_run`	No	If true with filter_dsl, parse and validate DSL without executing the query
`query_dsl`	No	Query DSL for recommend, discover, fusion, or order-by queries
`collection`	No	Qdrant collection to search. Default: mcp_tool_responses
`filter_dsl`	No	Qdrant DSL filter notation for precise filtering (see docstring for symbols)
`prefetch_dsl`	No	Multi-stage prefetch DSL for hierarchical search strategies
`score_threshold`	No	Minimum similarity score (0.0-1.0)
`user_google_email`	No	User's Google email (auto-injected by middleware)
`negative_point_ids`	No	Point IDs to use as negative examples for recommendation search
`positive_point_ids`	No	Point IDs to use as positive examples for recommendation search

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It explicitly states the tool is read-only, that no Google APIs are called, the exact return row format, the two error messages ('Search failed', 'No results'), and the effect of score_threshold. This is far more transparent than typical tool descriptions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded: purpose, use-when, modes, behavior, returns, errors, then reference material. It is long, but the DSL symbol tables and examples earn their place because the schema refers to 'see docstring for symbols.' A minor redundancy between the 'Modes' section and the query parameter description prevents a perfect score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 11-parameter tool with no output schema and no annotations, this description is remarkably complete: it covers return shape, error behavior, default threshold semantics, DSL syntax, example queries, sibling routing, and parameter mode mappings. An agent has nearly everything needed to invoke it correctly and interpret the response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, giving a baseline of 3, but the description adds substantial meaning beyond the schema: a DSL symbol legend, a worked filter_dsl example, a MatchAny example, mapping of query_dsl/filter_dsl/prefetch_dsl to modes, explanation of positive/negative point IDs, and guidance to lower score_threshold. This meaningfully helps an agent construct parameters correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description opens with a specific verb and resource: 'Search the Qdrant vector store of this server's past tool responses and card templates.' It also names sibling tools and clarifies what they do instead, so an agent can distinguish semantic_search from search and fetch_document without ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Use when' section explicitly lists trigger conditions: looking up previous results, usage history, or analytics, with concrete query examples. It also provides exclusion guidance: 'For discovering tools to call, use search; to preview one stored document, pass its point ID to fetch_document.' This is exactly the when/when-not context an agent needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tagsTagsA

List this server's tool tags (service areas like gmail, drive, docs, photos) with tool counts. Use when: browsing what capability areas exist before a targeted lookup. For keyword lookup use search; for parameters of known tools use get_schema. Returns: '- tag (N tools)' lines at detail='brief' (default), or every tool listed under each tag at detail='full'.

ParametersJSON Schema

Name	Required	Description	Default
`detail`	No	Level of detail: 'brief' for tag names and counts, 'full' for tools listed under each tag	brief

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden, and it does well: it specifies the exact output shape at default detail ('- tag (N tools)' lines) and the change at detail='full'. It clearly frames the operation as a non-mutating listing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact sentences front-load the core action and use case before return details. There is no filler or unnecessary repetition of schema content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with one optional schema-defined parameter and no output schema, the description covers purpose, routing, default behavior, and return format. Nothing material needed to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already fully documents the single parameter with its enum, default, and per-value meaning, so the baseline is 3. The description adds the concrete output format for brief detail and confirms what full detail returns, which is a small but meaningful addition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise action ('List this server's tool tags...') with resource and scope, plus concrete examples of categories like gmail, drive, docs, and photos. The mention of tool counts and the overview nature distinguishes it from sibling tools such as search and get_schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the intended use case ('browsing what capability areas exist before a targeted lookup') and names alternatives for adjacent cases: 'For keyword lookup use search; for parameters of known tools use get_schema.' This gives an agent clear routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tool_activityTool ActivityA

Show usage analytics for this server's tools: call counts, error rates, last-used times.

Use when: answering 'what has been used or failing lately'. To read an individual response, pass a sample point ID to fetch_document; to discover tools to call, use search instead.

Behavior: read-only aggregation over the Qdrant response store. Returns: a text dashboard grouped by tool_name or user_email, with sample point IDs per group. Errors: 'Analytics failed' when the response store is unreachable.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum groups to show
`group_by`	No	Group results by 'tool_name' or 'user_email'	tool_name
`user_google_email`	No	User's Google email (auto-injected by middleware)

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses read-only behavior ('read-only aggregation over the Qdrant response store'), return format ('text dashboard... with sample point IDs per group'), and an error condition ('Analytics failed' when the response store is unreachable). It does not mention authentication or rate limits, but for this tool the provided behavioral details are substantive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well structured with labeled segments ('Use when', 'Behavior', 'Returns', 'Errors'), front-loads the core purpose, and every sentence adds distinct value. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema and no annotations, the description provides enough context for correct invocation: what it returns (text dashboard), how it groups, what error to expect, and when to use alternatives. All three optional parameters are already covered by the schema, so nothing needed for this tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter is already documented in the schema. The description mentions grouping by tool_name or user_email, which mirrors the group_by schema description, but does not add new semantic detail beyond that. Baseline 3 is appropriate when the schema handles parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('Show usage analytics for this server's tools: call counts, error rates, last-used times'), and later explicitly contrasts with fetch_document and search, distinguishing its purpose. An agent can immediately tell what this tool does and how it differs from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Contains explicit 'Use when' guidance ('answering what has been used or failing lately'), plus clear redirections: 'pass a sample point ID to fetch_document' and 'use search instead'. This leaves no ambiguity about when to select this tool over alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv3.0.0Sep 3, 2026

Changedfetch_document1 field changed

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "result": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "type": "object",
-  "x-fastmcp-wrap-result": true
-}New value: +null

Changedget_schema1 field changed

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "result": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "type": "object",
-  "x-fastmcp-wrap-result": true
-}New value: +null

Changedsearch1 field changed

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "result": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "type": "object",
-  "x-fastmcp-wrap-result": true
-}New value: +null

Changedsemantic_search1 field changed

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "result": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "type": "object",
-  "x-fastmcp-wrap-result": true
-}New value: +null

Changedtags1 field changed

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "result": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "type": "object",
-  "x-fastmcp-wrap-result": true
-}New value: +null

Changedtool_activity1 field changed

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "result": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "type": "object",
-  "x-fastmcp-wrap-result": true
-}New value: +null

103 tool updatesv2.3.2Aug 7, 2026
- Removedadd_questions_to_form
- Removedadd_slide
- Removedbulk_calendar_operations
- Removedcheck_drive_auth
- Removedcleanup_qdrant_data
- Removedcompose_dynamic_email
- Removedcreate_calendar
- Removedcreate_doc
- Removedcreate_drive_file
- Removedcreate_event
- Removedcreate_form
- Removedcreate_gmail_filter
- Removedcreate_photos_album
- Removedcreate_presentation
- Removedcreate_sheet
- Removedcreate_spreadsheet
- Removedcreate_template_macro
- Removeddelete_event
- Removeddelete_gmail_filter
- Removeddownload_gmail_attachment
- Removeddraft_gmail_forward
- Removeddraft_gmail_message
- Removeddraft_gmail_reply
- Addedexecute
- Removedexport_and_download_presentation
- Removedfetch
- Addedfetch_document
- Removedformat_sheet_range
- Removedforward_gmail_message
- Removedget_doc_content
- Removedget_drive_file_content
- Removedget_event
- Removedget_form
- Removedget_form_response
- Removedget_gmail_filter
- Removedget_gmail_message_content
- Removedget_gmail_messages_content_batch
- Removedget_gmail_thread_content
- Removedget_people_contact_group_members
- Removedget_photo_details
- Removedget_photos_library_info
- Removedget_presentation_info
- Removedget_response_details
- Addedget_schema
- Removedget_spreadsheet_info
- Removedget_tool_analytics
- Removedhealth_check
- Removedlist_album_photos
- Removedlist_calendars
- Removedlist_docs_in_folder
- Removedlist_drive_items
- Removedlist_events
- Removedlist_form_responses
- Removedlist_gmail_filters
- Removedlist_gmail_labels
- Removedlist_messages
- Removedlist_people_contact_labels
- Removedlist_photos_albums
- Removedlist_spaces
- Removedlist_spreadsheets
- Removedmake_drive_files_public
- Removedmanage_credentials
- Removedmanage_drive_files
- Removedmanage_gmail_allow_list
- Removedmanage_gmail_label
- Removedmanage_people_contact_labels
- Removedmanage_space
- Removedmanage_tools
- Removedmodify_event
- Removedmodify_gmail_message_labels
- Removedmodify_sheet_values
- Removedmove_events_between_calendars
- Removedphotos_batch_details
- Removedphotos_optimized_album_sync
- Removedphotos_performance_stats
- Removedphotos_smart_search
- Removedpublish_form_publicly
- Removedqdrant_search
- Removedread_sheet_values
- Removedreply_to_gmail_message
- Addedsearch
- Removedsearch_docs
- Removedsearch_drive_files
- Removedsearch_gmail_messages
- Removedsearch_messages
- Removedsearch_photos
- Removedsearch_tool_history
- Addedsemantic_search
- Removedsend_dynamic_card
- Removedsend_gmail_message
- Removedsend_message
- Removedset_form_publish_state
- Removedset_privacy_mode
- Removedshare_drive_files
- Removedstart_google_auth
- Addedtags
- Addedtool_activity
- Removedupdate_form_questions
- Removedupdate_slide_content
- Removedupload_folder_photos
- Removedupload_photos
- Removedupload_to_drive
- Removedverify_payment
96 tool updatesv2.2.1Jul 9, 2026
- First observedadd_questions_to_form
- First observedadd_slide
- First observedbulk_calendar_operations
- First observedcheck_drive_auth
- First observedcleanup_qdrant_data
- First observedcompose_dynamic_email
- First observedcreate_calendar
- First observedcreate_doc
- First observedcreate_drive_file
- First observedcreate_event
- First observedcreate_form
- First observedcreate_gmail_filter
- First observedcreate_photos_album
- First observedcreate_presentation
- First observedcreate_sheet
- First observedcreate_spreadsheet
- First observedcreate_template_macro
- First observeddelete_event
- First observeddelete_gmail_filter
- First observeddownload_gmail_attachment
- First observeddraft_gmail_forward
- First observeddraft_gmail_message
- First observeddraft_gmail_reply
- First observedexport_and_download_presentation
- First observedfetch
- First observedformat_sheet_range
- First observedforward_gmail_message
- First observedget_doc_content
- First observedget_drive_file_content
- First observedget_event
- First observedget_form
- First observedget_form_response
- First observedget_gmail_filter
- First observedget_gmail_message_content
- First observedget_gmail_messages_content_batch
- First observedget_gmail_thread_content
- First observedget_people_contact_group_members
- First observedget_photo_details
- First observedget_photos_library_info
- First observedget_presentation_info
- First observedget_response_details
- First observedget_spreadsheet_info
- First observedget_tool_analytics
- First observedhealth_check
- First observedlist_album_photos
- First observedlist_calendars
- First observedlist_docs_in_folder
- First observedlist_drive_items
- First observedlist_events
- First observedlist_form_responses
- First observedlist_gmail_filters
- First observedlist_gmail_labels
- First observedlist_messages
- First observedlist_people_contact_labels
- First observedlist_photos_albums
- First observedlist_spaces
- First observedlist_spreadsheets
- First observedmake_drive_files_public
- First observedmanage_credentials
- First observedmanage_drive_files
- First observedmanage_gmail_allow_list
- First observedmanage_gmail_label
- First observedmanage_people_contact_labels
- First observedmanage_space
- First observedmanage_tools
- First observedmodify_event
- First observedmodify_gmail_message_labels
- First observedmodify_sheet_values
- First observedmove_events_between_calendars
- First observedphotos_batch_details
- First observedphotos_optimized_album_sync
- First observedphotos_performance_stats
- First observedphotos_smart_search
- First observedpublish_form_publicly
- First observedqdrant_search
- First observedread_sheet_values
- First observedreply_to_gmail_message
- First observedsearch_docs
- First observedsearch_drive_files
- First observedsearch_gmail_messages
- First observedsearch_messages
- First observedsearch_photos
- First observedsearch_tool_history
- First observedsend_dynamic_card
- First observedsend_gmail_message
- First observedsend_message
- First observedset_form_publish_state
- First observedset_privacy_mode
- First observedshare_drive_files
- First observedstart_google_auth
- First observedupdate_form_questions
- First observedupdate_slide_content
- First observedupload_folder_photos
- First observedupload_photos
- First observedupload_to_drive
- First observedverify_payment

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored 2026-09-09 23:48 across 7 tools

Disambiguation4/5

The tools are mostly separable: tags and search provide different discovery paths, and semantic_search is clearly scoped to past responses. The main ambiguity is that search, semantic_search, and tags all surface tool/response names in slightly different ways, though the descriptions mitigate this by stating when to use each.

Naming Consistency3/5

All names use lowercase with underscores, but the structural conventions are mixed: standalone verbs (search, execute), nouns (tags, tool_activity), and verb_noun compounds (get_schema, fetch_document) coexist. This is readable, but there is no single consistent naming pattern across the tool set.

Tool Count5/5

Seven tools is an appropriate, well-scoped count for a discovery, schema, execution, history, and analytics server. Each tool carries a distinct responsibility, with no obvious redundancy or bloat.

Completeness4/5

The tool surface covers the core lifecycle of discovering tools, fetching schemas, executing calls, and retrieving historical results/analytics. Minor gaps exist, such as no dedicated tool for deleting/cleaning stored history or batch management of point IDs, but these are workable around.

Maintenance

ActivityActive

ResponsivenessSlow

Resources

Need Help?

Related Servers

Related MCP Connectors

ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24
ToolforestOAuth
io.toolforest
Hosted MCP server with managed OAuth for 15+ toolkits: Google Workspace, Fitbit, Oura, Kalshi, etc.
Workplace & Productivity Health & Wellness Finance
2
FlowraOAuth
io.github.flowradev
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Agent Orchestration Autonomous Agents
11
argo-mcp A
io.github.Argo-RPG-Platform
MCP server for Argo RPG Platform — connects AI assistants to campaign data via OAuth2
Games & Gamification Knowledge & Memory
6321

Related MCP Servers

Google Toolbox
Search Calendar Management Cloud Storage
jikime
A
license
B
quality
D
maintenance
Google Toolbox
Updated a year ago (2025-05-06 07:36 UTC)
11
10
Apache 2.0
mcp-google-workspace
Workplace & Productivity Email Calendar Management
guinacio
A
license
B
quality
A
maintenance
MCP server integrating multiple Google Workspace services including Gmail, Calendar, Drive, Sheets, Docs, Tasks, People, Forms, and Slides, enabling users to manage emails, events, files, documents, and more through natural language.
Updated 10 days ago (2026-10-02 20:12 UTC)
15
MIT
gsuite
Email Calendar Management Workplace & Productivity
w-10-m
A
license
B
quality
C
maintenance
Comprehensive Google Workspace MCP server with Gmail, Drive, Calendar, and Contacts integration.
Updated 10 months ago (2025-12-25 08:18 UTC)
26
14 npm
MIT
google-cli-mcp
Workplace & Productivity Communication Calendar Management
ChrisNoronha
F
license
Not graded
quality
D
maintenance
An MCP server that exposes 17 Google Workspace APIs (e.g., Gmail, Drive, Calendar) as auto-generated tools for AI assistants, enabling natural language control of Google services.
Updated 7 months ago (2026-03-25 21:27 UTC)
-

🚀 GoogleUnlimited Google Workspace プラットフォーム

📋 目次

⚡ クイックインストール手順

GoogleUnlimited とは？

🛠️ インストール方法

方法1：uvx によるクイックインストール（推奨）

方法1b：Claude Code プラグイン（サーバー＋スキル）

方法2：クローンと開発セットアップ

📋 環境変数リファレンス

🔗 クライアント接続

🎯 クイックセットアップオプション

🤖 Claude Code と Claude Desktop

📚 完全な接続ガイド

⚡ コードモード（デフォルト）

🎯 サービス機能

🧠 ミドルウェアアーキテクチャ

🔧 コアミドルウェアコンポーネント

✨ アーキテクチャの利点

🚀 最小ツール起動

🔧 セッションスコープのツール管理

📚 スキルプロバイダー

🖥️ ツール管理ダッシュボード

🔗 URLベースのサービスフィルタリング（HTTPトランスポート）

🎨 テンプレートシステム

🎯 利用可能なテンプレートマクロ

💡 テンプレートマクロの例

🔍 マクロの発見と動的作成

🎯 動的マクロ作成

🚀 実世界での使用例

🗂️ リソースディスカバリー

🎯 リソース URI パターン

🏗️ 主要なリソースファイル

⚡ 電光石火のアクセス

🧪 テストフレームワーク

🎯 クライアントテストの焦点

🚀 クイックテストコマンド

🔬 実際のリソース ID 統合

🔄 CI/CD パイプライン

🔒 セキュリティと認証

🛡️ 認証フロー

✨ セキュリティ機能

⚙️ セキュリティ設定

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches