Skip to main content
Glama
enesjakozh
penysho

Google Docs MCP Server

by penysho
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Google Docs MCP Server

Google Docs APIと連携するMCP（Model Context Protocol）サーバーです。AI システムがGoogle Docsを直接操作できるインターフェースを提供します。

機能

このMCPサーバーが提供するツール：

  • read_google_document - Google Docsドキュメントの読み取り

  • create_google_document - 新しいGoogle Docsドキュメントの作成

  • update_google_document - 既存のGoogle Docsドキュメントの更新

  • search_google_documents - Google Docsドキュメントの検索

Related MCP server: Claude MCP x Google Docs

アーキテクチャの特徴

  • 依存性注入コンテナ - ServiceContainerによるサービス管理

  • 階層化エラーハンドリング - 統一されたエラー処理システム

  • 自動ツール登録 - 設定ベースのツール管理

  • 完全なTypeScript - 型安全性と開発効率の向上

技術スタック

セットアップ

1. プロジェクトの準備

git clone <repository-url>
cd docs-mcp
npm install

2. Google Cloud Platform の設定

  1. Google Cloud Console でプロジェクトを作成

  2. 以下のAPIを有効化：

    • Google Docs API

    • Google Drive API

  3. OAuth 2.0 クライアントIDを作成し、認証情報をダウンロード

  4. credentials.json としてプロジェクトルートに配置

3. 環境設定（オプション）

.env ファイルで設定をカスタマイズできます：

# アプリケーション環境 (development, production, test)
NODE_ENV=development

# ログ設定 (ERROR, WARN, INFO, DEBUG, TRACE)
LOG_LEVEL=INFO
LOG_USE_STDERR=true

# サーバー情報
SERVER_NAME=google-docs-mcp-server
SERVER_VERSION=1.0.0

# 認証ファイルパス（カスタマイズ可能）
CREDENTIALS_PATH=./credentials.json
TOKEN_PATH=./token.json

4. 初回認証

npm run dev

ターミナルに表示される認証URLにアクセスし、Googleアカウントで認証してください。認証後に取得したコードをターミナルに入力すると token.json が生成されます。

開発コマンド

# 開発サーバー（hot reload）
npm run dev

# プロダクションビルド
npm run build

# ビルド後の実行
npm start

# MCP デバッグモード
npm run mcp

# コード品質チェック
npm run lint

ビルドプロセス: TypeScript コンパイル → 実行権限設定 → 認証ファイル複製

MCP クライアント設定

Cursor での設定

.cursor/mcp.json に追加：

{
  "mcpServers": {
    "google-docs": {
      "command": "node",
      "args": ["/absolute/path/to/docs-mcp/dist/index.js"]
    }
  }
}

Claude Desktop での設定

claude_desktop_config.json に追加：

{
  "mcpServers": {
    "google-docs": {
      "command": "node",
      "args": ["/absolute/path/to/docs-mcp/dist/index.js"]
    }
  }
}

注意: ビルド後の dist/index.js を指定してください。

提供ツール

read_google_document

Google Docs ドキュメントの内容を読み取ります。

パラメータ:

  • documentId (string): 読み取るドキュメントのID

create_google_document

新しい Google Docs ドキュメントを作成します。

パラメータ:

  • title (string): ドキュメントタイトル

  • content (string, オプション): 初期内容

update_google_document

既存の Google Docs ドキュメントを更新します。

パラメータ:

  • documentId (string): 更新するドキュメントのID

  • content (string): 追加または更新するコンテンツ

  • startPosition (number, オプション): 更新開始位置

  • endPosition (number, オプション): 更新終了位置

search_google_documents

Google Docs ドキュメントを検索します。

パラメータ:

  • query (string): 検索クエリ

  • maxResults (number, オプション): 最大結果数（デフォルト: 10）

プログラムでの利用例

MCP SDK を使用した TypeScript/JavaScript での利用：

import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";

async function main() {
  const client = new Client({
    name: "google-docs-client",
    version: "1.0.0"
  });

  const transport = new StdioClientTransport({
    command: "node",
    args: ["/absolute/path/to/docs-mcp/dist/index.js"]
  });

  await client.connect(transport);

  // ドキュメント検索
  const searchResult = await client.callTool({
    name: "search_google_documents",
    arguments: {
      query: "会議資料",
      maxResults: 5
    }
  });

  // 新規ドキュメント作成
  const createResult = await client.callTool({
    name: "create_google_document",
    arguments: {
      title: "新しいドキュメント",
      content: "初期コンテンツ"
    }
  });

  await client.disconnect();
}

main().catch(console.error);

アーキテクチャ詳細

コアコンポーネント

  • ServiceContainer (src/core/container.ts) - 依存性注入とサービスライフサイクル管理

  • GoogleDocsMcpServer (src/mcp/server.ts) - MCP サーバーの管理と初期化

  • ToolRegistry (src/mcp/registry.ts) - ツールの自動登録システム

  • BaseMcpTool (src/mcp/tools/base.ts) - 全ツールの共通基底クラス

サービス層

  • AuthService (src/services/authService.ts) - Google OAuth2 認証管理

  • GoogleDocsService (src/services/googleDocsService.ts) - Google Docs/Drive API操作

設定システム

  • 統一設定管理 (src/config/index.ts) - 環境変数とデフォルト値の統合

  • 型安全な設定 - Zod による設定値の検証

  • 階層化ログシステム (src/utils/logger.ts) - モジュール別ログ出力

トラブルシューティング

MCP クライアント接続エラー

  1. ビルドの確認: npm run build が成功しているか

  2. パス設定: 設定ファイルで dist/index.js への絶対パスを指定

  3. 権限設定: chmod 755 dist/index.js で実行権限を確認

  4. 手動テスト: npm run mcp でサーバーが起動するか確認

Google 認証エラー

  1. 認証ファイル: credentials.json がプロジェクトルートに存在するか

  2. API有効化: Google Cloud Console で必要なAPIが有効か

  3. トークン再作成: token.json を削除して再認証

  4. スコープ確認: Docs API と Drive API の権限が設定されているか

開発時のデバッグ

# 詳細ログでデバッグ実行
LOG_LEVEL=DEBUG npm run dev

# MCP通信のデバッグ
npm run mcp

拡張ガイド

新しいツールの追加

  1. src/mcp/tools/ に新しいツールクラスを作成

  2. BaseMcpTool を継承して実装

  3. ToolRegistry.registerDefaultTools() に追加

サービスの拡張

  1. src/core/interfaces.ts でインターフェースを定義

  2. src/services/ に実装クラスを作成

  3. ServiceContainer に追加

注意事項

  • 初回実行時の Google 認証が必要

  • Google Cloud Platform の API 使用料金が発生する可能性

  • MCP クライアントでは絶対パスでの指定が必要

ライセンス

MIT License

Available Tools

4 tools
create_google_documentD
ParametersJSON Schema
NameRequiredDescriptionDefault
contentNoドキュメントの初期内容（オプション）
titleYes新しいドキュメントのタイトル

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

read_google_documentD
ParametersJSON Schema
NameRequiredDescriptionDefault
documentIdYes読み取るGoogle DocsドキュメントのID

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

search_google_documentsD
ParametersJSON Schema
NameRequiredDescriptionDefault
maxResultsNo取得する最大結果数（デフォルト: 10）
queryYes検索クエリ

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

update_google_documentD
ParametersJSON Schema
NameRequiredDescriptionDefault
contentYes追加または更新するコンテンツ
documentIdYes更新するGoogle DocsドキュメントのID
endPositionNo更新を終了する位置（オプション）
startPositionNo更新を開始する位置（オプション）

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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.

  1. 4 tool updatesv1.0.0
    • First observedcreate_google_document
    • First observedread_google_document
    • First observedsearch_google_documents
    • First observedupdate_google_document
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

C2/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose targeting a specific operation in the Google Docs domain: create, read, search, and update. There is no overlap or ambiguity between these core functions, making it easy for an agent to select the right tool for each task.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with 'google_document' as the common noun component. The verbs (create, read, search, update) are standard and uniformly formatted in snake_case, providing excellent predictability and readability.

Tool Count4/5

With 4 tools, the count is appropriate for basic document operations, though it feels slightly thin for a full Google Docs server. Core CRUD functions are covered, but additional tools for deletion or more advanced features might be expected in a broader scope.

Completeness3/5

The toolset covers create, read, search, and update operations, which handles basic workflows, but there are notable gaps. Missing a delete tool prevents full lifecycle management, and other common document operations like sharing or formatting are absent, limiting comprehensive coverage of the domain.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches