Skip to main content
Glama
enesjakozh
HosakaKeigo

Spreadsheet MCP Server

by HosakaKeigo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

电子表格 MCP 服务器

该项目是一个用于访问 Google 电子表格中的数据的模型上下文协议 (MCP) 服务器。允许 LLM 直接使用电子表格信息。

功能

  • 获取有关电子表格的基本信息（例如工作表列表）

  • 从特定工作表中获取数据并将其格式化为 Markdown 格式

  • 与 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 应用网址

  • 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

提供的工具

获取电子表格

获取有关电子表格的基本信息以及其中包含的工作表列表。

输入参数：

  • url ：电子表格的 URL

输出：

  • 电子表格名称、ID、工作表列表（包括行数和列数）

获取工作表数据

从电子表格中的特定工作表获取数据。

输入参数：

  • url ：电子表格的 URL

  • sheetName ：要获取的工作表的名称

输出：

  • 工作表数据（Markdown表格格式）

发展

项目结构

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 脚本集成

在实际使用中，该服务器与 Google Apps Script Web App 配合使用：

  1. 使用 Google Apps 脚本创建Web 应用

  2. 实现一个 API 来访问 Web 应用程序端的电子表格（请参阅api/README.md ）

  3. 设置 API 密钥并将其与环境变量GAS_WEB_APP_URL和GAS_API_KEY关联

这种方法可以让您避免 Google 身份验证流程并维护电子表格的安全性。

如果没有设置环境变量，脚本将以模拟模式运行并返回测试数据。

执照

麻省理工学院

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