Integrates with GitHub Copilot to allow reading and writing Excel files, including listing sheets, reading data in JSON or array format, creating files, adding sheets, and updating cells.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-xlsx-server list sheets in monthly_report.xlsx"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
基于 SheetJS (xlsx) 的 Excel 文件读写 MCP 服务。
提供 5 个 MCP 工具：
工具 | 功能 |
| 列出 xlsx 文件中所有 sheet 名称和行列数 |
| 读取指定 sheet 数据，支持 JSON/二维数组格式和范围选择 |
| 从 JSON 数据创建新的 xlsx 文件 |
| 向已有 xlsx 文件添加新 sheet |
| 更新指定单元格值 |
Related MCP server: MCP Excel Server
npm install -g mcp-xlsx-server或直接运行：
npx mcp-xlsx-server编辑 claude.json，使用 mcpServers 字段：
{
"mcpServers": {
"xlsx": {
"command": "npx",
"args": ["mcp-xlsx-server"]
}
}
}编辑 .vscode/mcp.json 或全局 mcp.json，使用 servers 字段（不是 mcpServers）：
{
"servers": {
"xlsx": {
"type": "stdio",
"command": "npx",
"args": ["mcp-xlsx-server"]
}
}
}文件位置：
工作区级别: .vscode/mcp.json
全局: %APPDATA%\Code\User\mcp.json
编辑 cline.json 或 mcp.json，使用 mcpServers 字段：
{
"mcpServers": {
"xlsx": {
"command": "npx",
"args": ["-y", "mcp-xlsx-server"]
}
}
}编辑 .cursor/mcp.json，使用 mcpServers 字段：
{
"mcpServers": {
"xlsx": {
"command": "npx",
"args": ["mcp-xlsx-server"]
}
}
}列出 xlsx 文件中所有 sheet。
参数：
file_path (string, 必填): xlsx 文件路径
读取指定 sheet 的数据。
参数：
file_path (string, 必填): xlsx 文件路径
sheet (string|number, 必填): sheet 名称或索引 (从 0 开始)
format (string, 默认 "json"): "json" 返回对象数组, "array" 返回二维数组
range (string, 可选): 单元格范围，如 "A1:C10"
从 JSON 数据创建新的 xlsx 文件。
参数：
file_path (string, 必填): 输出路径
data (string, 必填): JSON 数据字符串
sheet_name (string, 默认 "Sheet1"): sheet 名称
overwrite (boolean, 默认 false): 是否覆盖已有文件
向已有 xlsx 文件添加新 sheet。
参数：
file_path (string, 必填): 已存在的 xlsx 文件路径
data (string, 必填): JSON 数据字符串
sheet_name (string, 必填): 新 sheet 名称
更新指定单元格。
参数：
file_path (string, 必填): xlsx 文件路径
sheet (string|number, 必填): sheet 名称或索引
cells (string, 必填): JSON 对象，如 {"A1": "值", "B2": 123}
# 克隆仓库
git clone https://github.com/lubo3395/mcp-xlsx-server.git
cd mcp-xlsx-server
# 安装依赖
npm install
# 开发模式 (热重载)
npm run dev
# 构建
npm run build
# 运行
npm start
# MCP Inspector 测试
npx @modelcontextprotocol/inspector node dist/index.jsMIT
向已有的 xlsx 文件中添加新的 sheet。
参数:
file_path (string, 必填): 已存在的 xlsx 文件路径
data (string, 必填): JSON 数据字符串 (同 xlsx_create 的 data 参数)
sheet_name (string, 必填): 新 sheet 名称 (不能与已有 sheet 重名)
返回:
file_path: 文件路径
sheet_name: 新 sheet 名称
rows: 数据行数
cols: 数据列数
sheets: 更新后的所有 sheet 名称列表
示例:
"往 test.xlsx 添加一个名为 成绩表 的 sheet" -> { file_path: "test.xlsx", data: '[{"姓名":"张三","成绩":90}]', sheet_name: "成绩表" }
错误处理:
Sheet 名称已存在: "Sheet "名称" 已存在。可用 ..."
文件不存在: "文件不存在: ..."
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | 已存在的 xlsx 文件路径 | |
| data | Yes | JSON 数据: 可以是对象数组或二维数组 | |
| sheet_name | Yes | 新 sheet 名称 (不能与已有 sheet 重名) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, consistent with adding a sheet. The description adds value by describing error conditions and return values, but does not disclose additional behavioral traits beyond what annotations provide. Moderate extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose first, then parameter details, return values, example, error handling. Front-loaded with main action, no unnecessary sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 required parameters and no output schema, the description covers return fields and errors. It is fairly complete but could provide slightly more detail on data JSON format constraints. Overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and descriptions for parameters already exist. The description adds cross-reference to xlsx_create's data parameter and clarifies data format (object array or 2D array). This adds useful meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (add a new sheet) and the resource (existing xlsx file), and distinguishes it from siblings like xlsx_create (which creates new files) and xlsx_list_sheets (which lists sheets). Specific verb+resource+scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the tool adds sheets to existing files, implicitly differentiating from xlsx_create. It provides examples and error messages for duplicate names and missing files, giving context on when to use. However, it does not explicitly state when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
从 JSON 数据创建新的 xlsx 文件。
参数:
file_path (string, 必填): 输出 xlsx 文件路径
data (string, 必填): JSON 数据字符串
对象数组格式: [{"姓名": "张三", "年龄": 30}, {"姓名": "李四", "年龄": 25}]
二维数组格式: [["姓名", "年龄"], ["张三", 30], ["李四", 25]]
sheet_name (string, 默认 "Sheet1"): sheet 名称
overwrite (boolean, 默认 false): 文件已存在时是否覆盖
返回:
file_path: 输出文件路径
sheet_name: sheet 名称
rows: 总行数
cols: 总列数
示例:
"创建 test.xlsx，包含 [{name:'张三',age:30},{name:'李四',age:25}]" -> { file_path: "test.xlsx", data: '[{"name":"张三","age":30},{"name":"李四","age":25}]' }
"覆盖已有文件" -> { file_path: "test.xlsx", data: "...", overwrite: true }
错误处理:
文件已存在且未设置 overwrite: "文件已存在: ..."
输出目录不存在: "输出目录不存在: ..."
数据格式无效: "数据格式无效: ..."
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | 输出 xlsx 文件路径 | |
| data | Yes | JSON 数据: 可以是对象数组 [{"col1":"val1",...}] 或二维数组 [["h1","h2"],["v1","v2"]] | |
| sheet_name | No | sheet 名称 | Sheet1 |
| overwrite | No | 如果文件已存在是否覆盖 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, and the description elaborates on destructive behavior (overwriting, error if exists and no overwrite). It also covers error conditions and return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for parameters, return values, examples, and error handling. It is comprehensive but slightly verbose in places (e.g., examples repeating param info).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully covers return values, all parameters, and error cases. It provides enough context for correct invocation without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds substantial value with detailed data format examples, explanation of JSON structures, and clarification of overwrite behavior. This goes well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new xlsx file from JSON data. It distinguishes from sibling tools which handle adding sheets, listing, reading, and updating cells.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides thorough parameter details, examples, and error handling. While it doesn't explicitly state when to use vs alternatives, the context makes it clear for creation tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出 xlsx 文件中所有 sheet 的名称、行数和列数。
参数:
file_path (string, 必填): xlsx 文件路径
返回:
file_path: 文件路径
sheets: Sheet 信息数组
name: Sheet 名称
rows: 行数
cols: 列数
示例:
"读取 test.xlsx 有哪些 sheet" -> { file_path: "test.xlsx" }
错误处理:
文件不存在: "文件不存在: <路径>"
不是 xlsx 文件: "不支持的文件格式: <路径>"
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | xlsx 文件路径 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
注释已声明 readOnlyHint=true、destructiveHint=false、idempotentHint=true，描述在此基础上补充了返回结构（sheets 数组含 name、rows、cols）和错误处理（文件不存在、格式不支持），增强了行为透明性，与注释不矛盾。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
描述采用分节结构（功能、参数、返回、示例、错误处理），信息组织清晰且前部加载目的。虽然略冗长，但整体紧凑有效，无冗余句子。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
对于简单工具，描述完整覆盖了功能、参数、返回值结构、错误情况和示例，结合注释已充分提供上下文。无输出 schema，但描述已明确返回格式，无需额外信息。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
输入模式中 file_path 描述已明确，schema 描述覆盖率为 100%，描述仅重复了 file_path 的说明，未增加额外语义，符合基线 3。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
描述明确说明了工具的动词（列出）和资源（xlsx 文件中的 sheet），并进一步说明返回名称、行数和列数。与兄弟工具（添加、创建、读取、更新单元格）有清晰区分，提供了具体操作范围。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述未说明何时使用此工具而非兄弟工具，也未提供不使用场景或前置条件。虽然错误处理部分提示了文件存在性和格式要求，但缺乏明确的'何时用/何时不用'指导。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
读取 xlsx 文件中指定 sheet 的数据，支持 JSON 对象数组和二维数组两种格式。
参数:
file_path (string, 必填): xlsx 文件路径
sheet (string|number, 必填): sheet 名称或索引 (从 0 开始)
format (string, 默认 "json"): 输出格式
"json": 返回对象数组 (第一行为表头)
"array": 返回二维数组
range (string, 可选): 单元格范围，如 "A1:C10"
header_row (number, 默认 0): 表头行号，仅 json 格式有效
返回:
sheet: 读取的 sheet 名称
rows: 数据行数
cols: 数据列数
data: 表格数据
format: 数据格式
示例:
"读取 test.xlsx 的 Sheet1" -> { file_path: "test.xlsx", sheet: "Sheet1" }
"读取 test.xlsx 第一个 sheet 的 A1 到 C10 范围" -> { file_path: "test.xlsx", sheet: 0, range: "A1:C10" }
"以二维数组格式读取" -> { file_path: "test.xlsx", sheet: "Sheet1", format: "array" }
错误处理:
sheet 不存在: "Sheet "名称" 不存在。可用的 sheet: ..."
sheet 索引无效: "Sheet 索引无效: ..."
文件不存在: "文件不存在: <路径>"
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | xlsx 文件路径 | |
| sheet | Yes | sheet 名称或索引 (从 0 开始) | |
| format | No | 输出格式: 'json' 返回对象数组 (第一行为表头), 'array' 返回二维数组 | json |
| range | No | 可选单元格范围, 如 'A1:C10' | |
| header_row | No | 表头行号 (仅 json 格式有效), 从 0 开始, 默认第一行为表头 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
注解已声明只读等特性，描述额外提供了错误处理细节和返回结构，增加价值。无矛盾。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
描述较长但结构清晰，包含参数、返回值、示例和错误处理，无冗余，适合复杂工具。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
对于只读工具，描述了所有参数、返回结构和错误处理，无需输出模式，非常完整。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
模式覆盖率100%，描述在基线之上提供了示例和默认值解释，但未添加大量新信息。略微超出基线。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
描述明确说明工具用于读取xlsx文件指定sheet的数据，支持两种格式，与兄弟工具（添加、创建、列出、更新）区分明显。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述通过示例隐含使用场景，但未显式说明何时不使用或替代工具。上下文清晰，但缺乏明确排除项。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
更新 xlsx 文件中指定 sheet 的单元格值。
参数:
file_path (string, 必填): xlsx 文件路径
sheet (string|number, 必填): sheet 名称或索引 (从 0 开始)
cells (string, 必填): 要更新的单元格，JSON 对象格式: {"A1": "值", "B2": 123, "C3": true}
返回:
file_path: 文件路径
sheet: 更新的 sheet
updated: 更新单元格数量
示例:
"把 test.xlsx 的 Sheet1 中 A1 改成 Hello" -> { file_path: "test.xlsx", sheet: "Sheet1", cells: '{"A1": "Hello"}' }
"批量修改多个单元格" -> { file_path: "test.xlsx", sheet: 0, cells: '{"A1": "标题", "B1": "值"}' }
错误处理:
cells 格式无效: "cells 格式无效: ..."
单元格引用无效: "单元格引用无效: ..."
sheet 不存在: "Sheet ... 不存在"
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | xlsx 文件路径 | |
| sheet | Yes | sheet 名称或索引 (从 0 开始) | |
| cells | Yes | 要更新的单元格, JSON 对象格式: {"A1": "值", "B2": 123} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds little beyond that—it states '更新' which is consistent with mutation, but does not disclose additional behavioral traits such as authorization needs, side effects on other cells, or file state changes. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for parameters, return, example, and error handling. It is efficient, front-loading the main purpose. However, it could be slightly more concise by reducing repetition of parameter names already in schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, but with annotations present, the description covers all parameters with examples and error cases. It provides enough context for an agent to use the tool effectively, though it lacks usage guidelines and behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by providing example usage (including JSON format for cells), returning structure, and error handling for invalid cells or sheet. This goes beyond the schema's simple type descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates cell values in a specified sheet, with specific verb '更新' and resource 'xlsx 文件中指定 sheet 的单元格值'. It is distinct from sibling tools like xlsx_read (read), xlsx_create (create), xlsx_add_sheet (add sheet), and xlsx_list_sheets (list sheets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 does not mention when not to use it or under what conditions. No context about prerequisites or ideal scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0xlsx_add_sheetxlsx_createxlsx_list_sheetsxlsx_readxlsx_update_cellsEach tool has a clear and distinct purpose: creating, adding sheets, listing, reading, and updating cells. No overlap in functionality.
All tools follow a consistent 'xlsx_verb_noun' pattern (e.g., xlsx_add_sheet, xlsx_create). The naming is uniform and predictable.
With 5 tools, the server is well-scoped. Each tool covers a necessary operation for xlsx file manipulation without redundancy or excess.
The tool set covers core CRUD-like operations (create, read, update, add sheets, list sheets). Minor gaps like deleting sheets or rows exist, but the surface is sufficient for common tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
This MCP server provides seamless access to Malaysia's government open data, including datasets, w…
MCP server for Product Management
The official MCP Server for the Mux API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lubo3395/mcp-xlsx-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
