Skip to main content
Glama
enesjakozh
HosakaKeigo

Spreadsheet MCP Server

by HosakaKeigo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Spreadsheet MCP Server

This project is a Model Context Protocol (MCP) server for accessing data from Google Spreadsheets, making the spreadsheet information directly available to LLM.

function

  • Acquiring basic information about a spreadsheet (such as a list of sheets)

  • Get data from a specific sheet and format it in Markdown format

  • Integrates with MCP clients (e.g. Claude for Desktop)

Related MCP server: MCP Google Workspace Server

install

# リポジトリのクローン
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

Setting environment variables

The following environment variables are used to configure the server:

  • GAS_WEB_APP_URL : Google Apps Script Web App URL

  • GAS_API_KEY : API key for accessing Google Apps Script Web App

You can set these environment variables in the .env file:

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

If the environment variable is not set, the server will operate in mock mode and will not access the actual Google Spreadsheet.

How to use

Standalone startup

npm start

Integration with Claude for Desktop

Add the following to your Claude for Desktop configuration file ( claude_desktop_config.json ):

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

To set an environment variable, add env field as follows:

{
  "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"
      }
    }
  }
}

The configuration file is located here:

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

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

Test with MCP Inspector

npx @modelcontextprotocol/inspector node build/index.js

Tools provided

getSpreadsheet

Gets basic information about a spreadsheet and a list of the sheets it contains.

Input parameters :

  • url : The URL of the spreadsheet

output :

  • Spreadsheet name, ID, list of sheets (including number of rows and columns)

getSheetData

Gets data from a specific sheet in a spreadsheet.

Input parameters :

  • url : The URL of the spreadsheet

  • sheetName : The name of the sheet to get

output :

  • Sheet data (Markdown table format)

development

Project Structure

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

test

# 単体テスト実行
npm test

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

Integration with Google Apps Script

In actual use, this server works in conjunction with a Google Apps Script Web App:

  1. Create a Web App with Google Apps Script

  2. Implement an API to access the spreadsheet on the web app side (see api/README.md )

  3. Set the API key and link it with the environment variables GAS_WEB_APP_URL and GAS_API_KEY

This approach allows you to avoid the Google authentication flow and maintain the security of your spreadsheet.

If the environment variable is not set, the script will operate in mock mode and return test data.

license

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