Skip to main content
Glama
enesjakozh
HosakaKeigo

Spreadsheet MCP Server

by HosakaKeigo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Spreadsheet MCP Server

이 프로젝트는 Google Spreadsheet 데이터에 액세스하기 위한 MCP(Model Context Protocol) 서버입니다. 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 웹 애플리케이션과 함께 작동합니다.

  1. Google Apps Script로 웹 앱 만들기

  2. 웹 앱에서 스프레드시트에 액세스하는 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