Skip to main content
Glama
enesjakozh
HosakaKeigo

Spreadsheet MCP Server

by HosakaKeigo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Spreadsheet MCP Server

このプロジェクトは、Google SpreadsheetのデータにアクセスするためのModel Context Protocol (MCP) サーバーです。LLMがスプレッドシート情報を直接利用できるようにします。

機能

  • スプレッドシートの基本情報（シート一覧など）の取得

  • 特定シートのデータの取得とマークダウン形式での整形

  • MCPクライアント（Claude for Desktopなど）と統合

Related MCP server: MCP Google Workspace Server

インストール

# リポジトリのクローン
git clone https://github.com/your-username/spreadsheet-mcp-server.git
cd spreadsheet-mcp-server

# 依存関係のインストール
npm install

# 環境変数の設定
cp .env.example .env
# .envファイルを編集してGAS_WEB_APP_URLとGAS_API_KEYを設定

# ビルド
npm run build

環境変数の設定

サーバーの設定には、以下の環境変数が使用されます：

  • GAS_WEB_APP_URL: Google Apps Script Web AppのURL

  • GAS_API_KEY: Google Apps Script Web Appのアクセス用APIキー

これらの環境変数は .env ファイルに設定できます：

GAS_WEB_APP_URL=https://script.google.com/macros/s/your-deployment-id/exec
GAS_API_KEY=your-api-key

環境変数が設定されていない場合、サーバーはモックモードで動作し、実際のGoogleスプレッドシートにはアクセスしません。

使用方法

スタンドアロンでの起動

npm start

Claude for Desktopとの統合

Claude for Desktopの設定ファイル (claude_desktop_config.json) に以下を追加します：

{
  "mcpServers": {
    "spreadsheet": {
      "command": "node",
      "args": ["<absolute-path-to-project>/build/index.js"]
    }
  }
}

環境変数を設定するには、以下のようにenvフィールドを追加します：

{
  "mcpServers": {
    "spreadsheet": {
      "command": "node",
      "args": ["<absolute-path-to-project>/build/index.js"],
      "env": {
        "GAS_WEB_APP_URL": "https://script.google.com/macros/s/your-deployment-id/exec",
        "GAS_API_KEY": "your-api-key"
      }
    }
  }
}

設定ファイルは以下の場所にあります：

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %AppData%\\Claude\\claude_desktop_config.json

MCP Inspectorでテスト

npx @modelcontextprotocol/inspector node build/index.js

提供するツール

getSpreadsheet

スプレッドシートの基本情報と含まれるシート一覧を取得します。

入力パラメータ:

  • url: スプレッドシートのURL

出力:

  • スプレッドシート名、ID、シート一覧（行数・列数を含む）

getSheetData

スプレッドシートの特定シートのデータを取得します。

入力パラメータ:

  • url: スプレッドシートのURL

  • sheetName: 取得するシート名

出力:

  • シートデータ（マークダウンテーブル形式）

開発

プロジェクト構造

src/
├── index.ts           # エントリポイント
├── server.ts          # MCPサーバー設定
├── config.ts          # 環境変数と設定管理
├── tools/             # ツール実装
│   ├── getSpreadsheet.ts
│   ├── getSheetData.ts
│   └── index.ts
├── api/               # API処理
│   ├── README.md      # API仕様
│   ├── spreadsheet.ts
│   └── types.ts
└── utils/             # ユーティリティ
    └── format.ts

テスト

# 単体テスト実行
npm test

# ウォッチモードでテスト
npm run test:watch

Google Apps Scriptとの連携について

このサーバーは、実際の使用時にはGoogle Apps ScriptのWeb Appと連携して動作します：

  1. Google Apps ScriptでWeb Appを作成する

  2. Webアプリ側でスプレッドシートにアクセスするAPIを実装する（api/README.md参照）

  3. APIキーを設定し、環境変数GAS_WEB_APP_URLとGAS_API_KEYで連携する

このアプローチにより、Google認証フローを回避し、スプレッドシートのセキュリティを維持できます。

環境変数が設定されていない場合は、モックモードで動作し、テスト用のデータが返されます。

ライセンス

MIT

Available Tools

2 tools
getSheetDataC

スプレッドシートの特定シートのデータを取得

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesスプレッドシートのURL
sheetNameYes取得するシート名

TDQS

C2.9/5.0
Behavior2/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 of behavioral disclosure. While '取得' (get) implies a read operation, the description doesn't specify whether this requires authentication, what format the data is returned in (e.g., array, object), whether there are rate limits, or if there are any side effects. For a data retrieval tool with zero annotation coverage, this leaves significant behavioral questions unanswered.

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 extremely concise - a single Japanese sentence that directly states the tool's function without any unnecessary words. It's front-loaded with the core purpose and contains zero redundant information. Every word earns its place in communicating the essential function.

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

Completeness2/5

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

Given that there's no output schema and no annotations, the description should provide more context about what the tool returns and how it behaves. The description only states what the tool does at a high level without addressing the return format, error conditions, or operational constraints. For a data retrieval tool with 2 parameters, this level of description is insufficient for an agent to understand the complete context of use.

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?

The schema description coverage is 100%, with both parameters ('url' and 'sheetName') fully documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline score is 3 even without parameter details in the description.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'スプレッドシートの特定シートのデータを取得' (Get data from a specific sheet in a spreadsheet). It specifies the verb ('取得' - get) and resource ('スプレッドシートの特定シートのデータ' - data from a specific sheet in a spreadsheet), making the function unambiguous. However, it doesn't explicitly differentiate from the sibling tool 'getSpreadsheet', which likely retrieves spreadsheet metadata rather than sheet data.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling tool 'getSpreadsheet' or explain scenarios where one would choose this tool over others. There's no information about prerequisites, constraints, or typical use cases beyond the basic function.

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

getSpreadsheetB

スプレッドシートの基本情報と含まれるシート一覧を取得

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesスプレッドシートのURL

TDQS

B3.1/5.0
Behavior2/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 of behavioral disclosure. It states the tool retrieves information (implying a read-only operation), but doesn't specify whether it requires authentication, has rate limits, returns paginated results, or handles errors. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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 a single, concise sentence in Japanese that directly states the tool's function without unnecessary words. It's front-loaded with the core purpose and efficiently communicates the scope. Every part of the sentence earns its place by specifying what is retrieved.

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

Completeness3/5

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

Given the tool's low complexity (one parameter, no annotations, no output schema), the description is minimally adequate. It covers the basic purpose but lacks details on usage guidelines, behavioral traits, and output format. Without annotations or an output schema, the description should ideally provide more context about what 'basic information' includes and how results are structured.

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?

The input schema has 100% description coverage, with the single parameter 'url' documented as 'spreadsheet URL.' The description doesn't add any semantic details beyond what the schema provides (e.g., URL format, validation rules). Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'get basic information of a spreadsheet and the list of sheets it contains.' It specifies the verb ('get') and resource ('spreadsheet'), making the function unambiguous. However, it doesn't explicitly differentiate from the sibling tool 'getSheetData,' which likely retrieves different data (e.g., cell contents vs. metadata).

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling tool 'getSheetData' or clarify the distinction between retrieving spreadsheet metadata versus sheet data. There's no context about prerequisites, limitations, or appropriate use cases beyond the basic function.

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. 2 tool updates
    • First observedgetSheetData
    • First observedgetSpreadsheet
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

B3.1/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: getSheetData retrieves data from a specific sheet within a spreadsheet, while getSpreadsheet provides metadata and a list of sheets for the entire spreadsheet. There is no overlap or ambiguity between these operations.

Naming Consistency5/5

Both tools follow a consistent verb_noun naming pattern (getSheetData and getSpreadsheet), using camelCase uniformly. The naming is predictable and readable across the tool set.

Tool Count2/5

With only 2 tools, this server feels thin for a spreadsheet domain, which typically requires operations like create, update, delete, or search. The count is too low for comprehensive coverage, limiting agent functionality.

Completeness2/5

The tool set is severely incomplete for spreadsheet operations, lacking essential CRUD actions such as creating or modifying sheets, updating cell data, or deleting content. This will cause significant agent failures in handling typical spreadsheet tasks.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches