Skip to main content
Glama
enesjakozh
HosakaKeigo

Spreadsheet MCP Server

by HosakaKeigo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Servidor MCP de hojas de cálculo

Este proyecto es un servidor de Protocolo de Contexto de Modelo (MCP) para acceder a datos en hojas de cálculo de Google. Permite que LLM utilice directamente la información de la hoja de cálculo.

función

  • Adquirir información básica sobre una hoja de cálculo (como una lista de hojas)

  • Obtener datos de una hoja específica y formatearla en formato Markdown

  • Se integra con clientes MCP (por ejemplo, Claude para escritorio)

Related MCP server: MCP Google Workspace Server

instalar

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

Configuración de variables de entorno

Las siguientes variables de entorno se utilizan para configurar el servidor:

  • GAS_WEB_APP_URL : URL de la aplicación web de Google Apps Script

  • GAS_API_KEY : Clave API para acceder a la aplicación web de Google Apps Script

Puede configurar estas variables de entorno en el archivo .env :

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

Si no se configura la variable de entorno, el servidor funcionará en modo simulado y no accederá a la hoja de cálculo de Google real.

Cómo utilizar

Startup independiente

npm start

Integración con Claude para escritorio

Agregue lo siguiente a su archivo de configuración de Claude for Desktop ( claude_desktop_config.json ):

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

Para establecer una variable de entorno, agregue env de la siguiente manera:

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

El archivo de configuración se encuentra aquí:

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

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

Prueba con MCP Inspector

npx @modelcontextprotocol/inspector node build/index.js

Herramientas proporcionadas

obtenerHoja de cálculo

Obtiene información básica sobre una hoja de cálculo y una lista de las hojas que contiene.

Parámetros de entrada :

  • url : La URL de la hoja de cálculo

producción :

  • Nombre de la hoja de cálculo, ID, lista de hojas (incluido el número de filas y columnas)

obtenerDatosDeHoja

Obtiene datos de una hoja específica en una hoja de cálculo.

Parámetros de entrada :

  • url : La URL de la hoja de cálculo

  • sheetName : El nombre de la hoja a obtener

producción :

  • Datos de la hoja (formato de tabla Markdown)

desarrollo

Estructura del proyecto

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

prueba

# 単体テスト実行
npm test

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

Integración con Google Apps Script

En el uso real, este servidor funciona junto con una aplicación web de Google Apps Script:

  1. Crear una aplicación web con Google Apps Script

  2. Implementar una API para acceder a la hoja de cálculo en el lado de la aplicación web (ver api/README.md )

  3. Establezca la clave API y vincúlela con las variables de entorno GAS_WEB_APP_URL y GAS_API_KEY

Este enfoque le permite evitar el flujo de autenticación de Google y mantener la seguridad de su hoja de cálculo.

Si no se configura la variable de entorno, el script funcionará en modo simulado y devolverá datos de prueba.

licencia

Instituto Tecnológico de Massachusetts (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