最近一直在折腾一个很有意思的方向用 MCP 协议把 AI 大模型接到日常办公工具里让 AI 真正“上手干活”而不只是聊天。折腾了一圈下来我最大的体会是如果你是第一次接触 MCP想找一个既能快速上手、又有实际价值的练手项目那“用 AI 重构 Excel 处理工作流”几乎是性价比最高的选择。MCPModel Context Protocol解决的核心问题是让 AI 不再停留在对话框里而是能直接驱动你电脑上的文件、软件和数据——相当于给大模型装上了一套标准化的“手和眼”。这篇文章我不打算空谈概念而是直接带你从零写一个能用的 Excel MCP Server再跑通几个真实的工作流场景让 AI 替你完成数据汇总、清洗和报表生成这些脏活累活。1. 为什么把 Excel 当作你的第一个 MCP 项目1.1 传统 Excel 处理的真实痛点先说说我为什么坚持把 Excel 这类任务放在最前面。日常办公里Excel 操作的频率实在太高了销售要汇总每个月的订单财务要核对报销明细运营要把导出的后台数据整理成报表。这些工作看起来不难但实际做起来极其消耗精力因为你面对的是大量重复性的机械操作——打开文件、找到行列、拖公式、复制粘贴、调格式。真要做一次两张表的合并你可能需要在 Excel 里点半天鼠标结果一不小心粘贴错了区域整个报表的数据就全乱了。更麻烦的是这类操作很难沉淀成可复用的能力。这周写了一个 VBA 宏处理考勤表下周换一张数据结构完全不同的表宏就废了。你当然可以用 Python 脚本去处理但对不擅长编程的人来说每次遇到新的 Excel 需求都要从零写脚本门槛又太高了。这时候引入 AI MCP 的思路就很自然把“理解需求”交给 AI把“执行操作”交给工具把“处理流程”沉淀成一套可随时调用的服务。1.2 MCP 是什么AI 世界的“万能插座”如果你第一次接触 MCP可以用一个类比来理解它就像 USB-C 接口。过去你想给各种设备充电、传数据、连显示器得准备一堆不同的线材和转接头USB-C 统一了物理接口后一根线就能解决大部分问题。MCP 就是 AI 应用和外部工具之间的那根“标准线”。在没有 MCP 之前大模型接入工具的方式是很混乱的。每个模型厂有自己的一套 function calling 规范每个应用接入一个第三方服务都要单独写一套对接逻辑。MCP 把这个环节标准化了工具提供方只要按照 MCP 协议封装成一个 Server任何支持 MCP 的客户端都能直接调用。对你这种想自己动手做工具的人来说最大的好处是——你辛苦写出来的 Excel 工具理论上可以在多个支持 MCP 的客户端里复用而不是绑定在某一个平台上。MCP 里的核心概念并不多弄清楚三个就够了Server 是提供能力的服务端比如你的 Excel 工具就运行在 Server 里Client 是发起请求的客户端比如你日常使用的 AI 助手Tool 是 Server 暴露给模型的功能单元比如“读取 Excel”“写入 Excel”“生成图表”。模型根据用户的自然语言描述动态决定调用哪个工具、传什么参数。1.3 选 Excel 作为练手项目的四个理由第一个理由是价值可见。做完一个 Excel MCP你能立刻在真实工作里用上效果很直观说一句话AI 帮你把表格整理好这种反馈比写一个“hello world”强烈得多。第二个理由是技术难度刚好。MCP 本身不难核心就是把函数暴露出去。但难点在于工具的边界设计、参数的合理规划、异常情况的处理——这些经验和问题在 Excel 场景里都能遇到又不会太复杂。第三个理由是周边生态成熟。Python 处理 Excel 的开源库非常多openpyxl、pandas、xlwings 都很成熟你不需要从零造轮子。我这次选择的是 Python openpyxl pandas 组合轻量、文档全、遇到问题好搜。第四个理由是场景可复制。Excel 只是第一个你跑通了这个链路后稍微改一改函数就能把邮件处理、PDF 文档整理、网页信息采集全部接入进来。我自己的项目路径就是这么走的先啃下 Excel再横向复制到别的工具上后面越做越顺。2. 环境准备与整体设计思路2.1 开发环境Python uv MCP SDK在开始动手之前先把环境搭起来。我用的主力语言是 Python版本最好在 3.10 以上因为 MCP 官方 SDK 对较新的语法特性有依赖。如果本机还没有一个干净的 Python 环境我强烈建议用 uv 来管理而不是直接往系统环境里装一堆依赖。uv 这个工具用起来很像 npm 的替代品创建虚拟环境、锁定依赖版本、执行脚本都非常顺手后面调试 MCP Server 时也不容易把环境搞乱。安装完 uv 后创建项目目录在里面建一个虚拟环境uv venv .venv source .venv/bin/activate然后安装核心依赖uv add mcp[cli] openpyxl pandas这里的mcp[cli]会带上命令行工具方便我们后面直接跑 MCP Inspector 来做调试。openpyxl 负责读写 xlsx 文件pandas 负责更复杂的数据聚合分析。这里有个小提示如果你只需要读写简单的表格只装 openpyxl 就够了pandas 更大也更重。我选择装上是因为后面做“按分组求和”这类操作时pandas 的 groupby 几个字就能搞定比手写循环优雅得多。2.2 先想清楚架构Server 长什么样很多第一次写 MCP 的人会犯一个错误上来就写代码写到一半发现不知道工具该怎么划分。我的建议是先想清楚你要暴露哪些“能力”再动手。所谓暴露能力就是定义 Tool 的粒度。我在设计 Excel MCP Server 时第一版把所有操作都拆成了很细的工具比如read_cell、write_cell、get_sheet_names。结果实际用起来体验很差因为 AI 模型在对话中处理复杂任务时会拆成很多步每步调用一个小工具来回交互几十次又慢又容易出错。后来我改成了面向任务的粗粒度工具比如read_excel一次读取一个范围内所有数据group_and_aggregate直接完成分组汇总generate_chart直接生成图表插入工作表。模型调用一个工具就能完成一大段操作效果立刻好了很多。这段时间我的体会是工具的粒度决定了 AI 编排的顺畅度。粒度太细模型容易在中间步骤迷路粒度适中模型能一次性拿到足够信息做判断。2.3 FastMCP 带来的开发体验提升我这次用了mcp.server.fastmcp.FastMCP这是官方 SDK 里一个偏高层封装的入口。相比直接用底层 Primitive 去写FastMCP 把“注册工具、声明 Schema、管理进程通信”这些繁琐工作都包掉了。你只需要定义普通的 Python 函数然后在上面加一个装饰器函数就能自动变成一个 MCP 工具。FastMCP 还有一个很省心的地方它会根据函数的类型注解自动推断参数描述。比如函数里写path: str它就知道 tool 的参数path是字符串类型如果你在 docstring 里写一句说明它也会把这句话作为工具的 description 传给模型。这意味着你不需要手动维护一份 JSON Schema开发速度能快不少。3. 从零实现一个可用的 Excel MCP Server3.1 第一个工具读取 Excel 并返回结构化数据我们先写最基础的能力——读取一个 Excel 文件的内容。这个工具是所有后续工作的前提因为 AI 要“看到”表格里有什么才能决定下一步怎么做。import json from pathlib import Path from mcp.server.fastmcp import FastMCP import openpyxl mcp FastMCP(Excel Helper) mcp.tool() def read_excel(path: str, sheet: str None, start_row: int 1, max_rows: int 50) - str: 读取 Excel 文件指定工作表的内容返回二维数组的 JSON 字符串。 Args: path: Excel 文件的完整路径。 sheet: 工作表名称缺省时读取第一个可见工作表。 start_row: 从第几行开始读取默认第 1 行通常为表头。 max_rows: 最多读取多少行防止返回数据量过大。 wb openpyxl.load_workbook(path, data_onlyTrue, read_onlyTrue) ws wb[sheet] if sheet else wb.active rows [] for row in ws.iter_rows(min_rowstart_row, max_rowstart_row max_rows - 1, values_onlyTrue): cleaned [ if v is None else str(v) for v in row] rows.append(cleaned) return json.dumps(rows, ensure_asciiFalse)注意两个细节。第一data_onlyTrue是很重要的参数它让 openpyxl 读取公式的计算结果而不是公式本身。如果你不设置这个读到的单元格里可能是SUM(A1:A10)这样的字符串对 AI 理解数据毫无价值。第二我用read_onlyTrue这个模式占内存很小处理大一点的表格不会卡死。max_rows这个参数也是我在实践过程中加上的。一开始没限制行数AI 读一张 10 万行的表时直接把返回数据撑爆了模型上下文根本放不下运行直接失败。后来改成默认只读 50 行并在 docstring 里告诉模型“默认最多读取 50 行可使用 max_rows 扩大范围”效果就稳定了。核心思路是不要让 AI 一次性背下整本字典让它按需翻页。3.2 第二个工具分组汇总和写入结果有“读”自然要有“写”。但光写一个write_cell意义不大我设计了一个更实用的组合工具根据指定列分组对值列求和然后把结果直接写到一个新工作表里。import pandas as pd mcp.tool() def group_sum_to_sheet(path: str, group_col: str, value_col: str) - str: 读取 Excel按指定列分组对另一列求和并把结果写入新工作表 汇总。 Args: path: Excel 文件的完整路径。 group_col: 用作分组依据的列名例如 地区。 value_col: 需要求和的数值列名例如 销售额。 df pd.read_excel(path) result df.groupby(group_col, as_indexFalse)[value_col].sum() out_path Path(path) with pd.ExcelWriter(out_path, engineopenpyxl, modea, if_sheet_existsreplace) as writer: result.to_excel(writer, sheet_name汇总, indexFalse) return f已生成汇总结果共 {len(result)} 行写入工作表 汇总。这里用modea是把结果追加到现有文件里。如果你需要保留原表和汇总表在同一个工作簿里这个模式很合适如果只想单独输出一个结果文件把path换成新路径即可。还有一个容易被忽略的点在真实场景里输入列名要和表格实际列名严格一致否则 pandas 会抛出 KeyError。我在写工具说明时专门加了“group_col 需要是表格中实际存在的列名”这一句让模型在调用前先去读表头而不是凭空猜列名。这一步看似多余实测下来能把失败率降低一大截。3.3 第三个工具生成图表并插入指定位置数据只有变成图表才更有说服力。openpyxl 本身支持在 xlsx 里插入图表我把它封装成了一个工具。mcp.tool() def generate_chart(path: str, sheet: str, min_col: int, max_col: int, max_row: int, chart_type: str bar) - str: 基于指定数据区域生成图表并插入工作表的右侧空白区域。 Args: path: Excel 文件的完整路径。 sheet: 要读取数据并插入图表的工作表名称。 min_col: 数据区域最小列号。 max_col: 数据区域最大列号。 max_row: 数据区域最大行号。 chart_type: 图表类型支持 bar / line / pie默认 bar。 wb openpyxl.load_workbook(path) ws wb[sheet] data openpyxl.chart.Reference(ws, min_colmin_col, min_row1, max_colmax_col, max_rowmax_row) if chart_type line: chart openpyxl.chart.LineChart() elif chart_type pie: chart openpyxl.chart.PieChart() else: chart openpyxl.chart.BarChart() chart.add_data(data, titles_from_dataTrue) ws.add_chart(chart, J2) wb.save(path) return f已生成 {chart_type} 图表插入到 {sheet} 的 J2 单元格位置。用同一个 Writer 循环跑三个工具先从read_excel读取原始数据再用group_sum_to_sheet生成汇总表最后用generate_chart基于汇总区域绘图整条链路就跑通了。这里我默认把图表放在 J2 位置是因为大部分表格的内容区域不会占用太宽的列如果你的表特别宽可以再暴露一个anchor_cell参数。3.4 启动 Server 并连接客户端调试写完这三个工具后启动 Server 非常简单if __name__ __main__: mcp.run()默认是 stdio 传输方式也就是通过标准输入输出和客户端通信适合在本机运行。如果你想通过网络被远程客户端调用可以用mcp.run(transportstreamable-http)这样会起一个 HTTP 服务客户端通过 URL 访问。实际操作中大多数首次开发场景用 stdio 就够了环境更简单出了问题好排查。连接客户端调试时我首推官方工具 MCP Inspectornpx modelcontextprotocol/inspector python excel_mcp_server.py运行后会起一个本地调试面板你可以直接在面板里列出工具、传入参数、查看返回结果非常直观。我每次开发新工具都会先在这里验证一遍确认工具本身没问题再接 AI 客户端做端到端测试。如果你用的是桌面类 MCP 客户端一般需要在客户端的配置文件里注册这个 Server。以 JSON 类型的配置为例大致是这样{ mcpServers: { excel-helper: { command: python, args: [/absolute/path/to/excel_mcp_server.py] } } }这里的 command 必须是绝对路径下的可执行 Pythonargs 也必须指向脚本的绝对路径。很多第一次跑不起来的案例都是因为用了相对路径或者没激活虚拟环境导致客户端找不到解释器。一个稳妥的做法是先which python查看当前虚拟环境 Python 的绝对路径然后在配置里填那个绝对路径。4. 三个真实工作流验证 AI 重构后的效率提升4.1 场景一销售数据自动汇总先拿一个常见的需求来测试有一个销售明细表包含日期、地区、销售员、销售额四列总计几千行。传统做法是你打开 Excel手动筛选地区或者用 SUMIF 函数一列一列地写公式用 AI MCP 就变成了一段自然语言对话“请读取这个文件按地区汇总销售额把结果写到新表里。”模型会根据工具描述自动调用read_excel先看结构再调用group_sum_to_sheet传入 group_col 为“地区”value_col 为“销售额”。整个过程在几十秒内完成而且不会因为手滑选错区域而出错。我可以反复用不同的字段问问题“按销售员汇总”“每个区域的订单数量是多少”模型会自动组合工具完成不同维度的分析。4.2 场景二脏数据清洗与格式修复现实中的 Excel 表格远比理想状态脏有空值、有多余空格、日期格式不一致、还有“1,234”这种带着千分位的文本。如果人工清洗光是“把数字当作文本存储”这个问题就能让人崩溃。我封装了一个清洗工具去掉首尾空格把纯数字字符串转成数字把不能识别的空单元格统一填成“缺失”。mcp.tool() def clean_sheet(path: str, sheet: str) - str: 清洗指定工作表中的常见脏数据并保存副本。 清洗规则 - 所有单元格去除首尾空格 - N/A、null、空字符串统一变为 None - 纯数字字符串转为浮点数 wb openpyxl.load_workbook(path, data_onlyTrue) ws wb[sheet] for row in ws.iter_rows(): for cell in row: val cell.value if val is None: continue if isinstance(val, str): val val.strip() if val.lower() in (n/a, null, ): val None else: try: val float(val) except ValueError: pass cell.value val out str(Path(path).with_name(Path(path).stem _cleaned.xlsx)) wb.save(out) return f清洗完成结果已保存为 {out}实际操作中我不建议直接覆盖原文件而是保存成带_cleaned后缀的新文件。原因很简单清洗规则不可能百分百正确如果 AI 理解错了需求把原始数据覆盖掉恢复成本太高。保留副本随时能回退。4.3 场景三从 Markdown 表格转换生成正式 Excel还有一个我经常遇到的场景在和 AI 对话过程中它直接给我输出一个 Markdown 格式的表格比如“给你的设备资产清单如下”。但 Markdown 表格在正式汇报里不实用我要的是格式良好的 xlsx 文件。这个需求也可以通过一个专用工具来做读取一段 Markdown 表格文本解析后写入 Excel。这个工具可以把“聊天记录里的表格数据”直接变成可编辑的 Excel 工作簿以后开会前整理例会数据非常方便。我在实践后总结出一个心得MCP 工具最好不要只映射“单个 Excel 操作”而要紧贴“用户的实际任务”。用户想要的不是“读文件”而是“把聊天里的表格落成一份正式的 Excel”。4.4 工作流重构后的整体效率对比这几件事如果放在以前我的操作时间大约是数据汇总 15~20 分钟脏数据清洗 20~40 分钟Markdown 转 Excel 至少要手动复制粘贴再调格式10 分钟左右。用 MCP 工具链跑下来大多数场景在 1 分钟内能完成且操作越是重复、数据量越大节省时间的效果就越明显。更重要的变化是认知层面的以前我面对一份新 Excel 是“打开软件开始点”现在我面对它时第一反应是“我可以怎么描述这个需求让模型自动处理”。这种从“手动操作”到“任务编排”的思维转变才是工作流重构的核心价值。5. 常见问题与排查技巧实录5.1 “工具加载不出来”怎么查第一次配置 MCP Server 时最常见的失败现象是客户端能识别到 Server但工具列表一直是空的或者调用时报错“tool not found”。我的排查顺序一般是固定的先用命令行直接跑一次python excel_mcp_server.py看有没有报语法错误或依赖错误再用 MCP Inspector 以同样的启动方式加载如果能列出工具说明 Server 本身没问题问题出在客户端的配置上。如果 Inspector 里也看不到工具优先看日志——很多时候是某个依赖没装上导入模块时抛了异常。还有一个小坑是环境问题。你在终端里激活了虚拟环境命令能正常跑但客户端配置里的command直接填的是“python”它可能指向了系统环境而不是虚拟环境。解决方式很简单配置里写command为虚拟环境里 Python 的绝对路径或者用一个 shell 脚本来激活环境后再启动。5.2 Excel 读写中的经典坑点处理 Excel 时有两类经典问题值得单独说。第一类是xls 和 xlsx 的兼容性问题。openpyxl 只支持 xlsx不支持老版的 xls。如果碰到老文件要么用xlrd库读取旧格式要么提示用户先另存为 xlsx。我在工具说明里特意写了一句“仅支持 xlsx 格式”省掉了很多无谓的尝试。第二类是文件占用问题。如果你在 Excel 软件里正开着这张表Python 脚本去写入时就会报权限错误因为 Windows 上 Excel 默认会把文件锁住。我在封装写入工具时会在写入前强行要求先关闭文件或者在 try except 里捕获 PermissionError返回一句“文件被占用请先关闭后再试”。这个细节虽然简单但能避免很多莫名其妙的失败。还有一类容易被忽略的是日期序列化。openpyxl 读取到的日期是 Python 的datetime对象直接json.dumps会报错。我在返回数据之前会把所有单元格统一转成字符串虽然这样损失了类型信息但对 AI 理解内容没有影响也让传输格式稳定。5.3 数据量太大导致 AI“失忆”的处理思路还有一个让我思考了很久的问题模型的上下文窗口是有限的不能把所有数据一股脑丢给它。遇到一张几万行的表时如果工具把全部内容都返回模型很容易遗漏重要信息甚至直接拒绝处理。我的处理方式是分层设计第一层工具只返回前 N 行预览数据让 AI 了解表结构第二层提供带筛选或聚合的工具让 AI 基于条件只提取需要的部分第三层是专门的汇总工具直接把计算结果返回给 AI而不是把原始数据透传。这一整套“先预览、再筛选、后聚合”的思路是整个 Excel MCP Server 里我认为最有价值的设计。提示如果你希望这个 Server 后续能被更多客户端复用尽量保持工具输入输出都以 JSON 字符串为主避免依赖客户端的特殊类型。JSON 是各类 MCP 客户端支持最好的格式。6. 从 Excel 开始把 MCP 能力复制到更多场景跑通第一个 Excel MCP Server 后你会发现这个开发流程具有很强的“复制性”。我现在手里已经有几个基于同一套思路扩展出来的工具一个用于批量整理 PDF 文档信息一个定时抓取网页表格并写入 Excel还有一个是把日常巡检记录自动生成日报。每个工具都是同样的套路——把任务拆成几个粗粒度的 Tool用 FastMCP 暴露再通过客户端自然语言编排。如果要把这份经验总结成一句话MCP 开发的重点从来不是协议本身而是你对任务的拆解能力。协议帮你解决了通信和调用的标准化问题但真正让 AI “好用”的是你把复杂任务拆成了哪些工具、每个工具的输入输出设计是否合理、异常处理是否完备。这些能力没有捷径只能通过真实项目去积累。我在实际做这个项目的过程中有一个体会特别深不要追求第一次就把工具做得多完美先跑通一个最小的闭环更重要。哪怕你只有一个read_excel工具先把 Server 跑起来接到客户端里自然语言问一句“这个表里有哪些列”看到模型能准确回答出来那种“打通了”的感觉会给你继续做下去的信心。后面再遇到新需求你只需要往 Server 里加函数、加装饰器功能就自然扩展出去了这个正反馈循环会推着你越走越远。 
长河君 · 2026/11/2 13:50:02 · 阅读 1.2k MCP实战：从零构建AI驱动的Excel自动化工作流
最近一直在折腾一个很有意思的方向用 MCP 协议把 AI 大模型接到日常办公工具里让 AI 真正“上手干活”而不只是聊天。折腾了一圈下来我最大的体会是如果你是第一次接触 MCP想找一个既能快速上手、又有实际价值的练手项目那“用 AI 重构 Excel 处理工作流”几乎是性价比最高的选择。MCPModel Context Protocol解决的核心问题是让 AI 不再停留在对话框里而是能直接驱动你电脑上的文件、软件和数据——相当于给大模型装上了一套标准化的“手和眼”。这篇文章我不打算空谈概念而是直接带你从零写一个能用的 Excel MCP Server再跑通几个真实的工作流场景让 AI 替你完成数据汇总、清洗和报表生成这些脏活累活。1. 为什么把 Excel 当作你的第一个 MCP 项目1.1 传统 Excel 处理的真实痛点先说说我为什么坚持把 Excel 这类任务放在最前面。日常办公里Excel 操作的频率实在太高了销售要汇总每个月的订单财务要核对报销明细运营要把导出的后台数据整理成报表。这些工作看起来不难但实际做起来极其消耗精力因为你面对的是大量重复性的机械操作——打开文件、找到行列、拖公式、复制粘贴、调格式。真要做一次两张表的合并你可能需要在 Excel 里点半天鼠标结果一不小心粘贴错了区域整个报表的数据就全乱了。更麻烦的是这类操作很难沉淀成可复用的能力。这周写了一个 VBA 宏处理考勤表下周换一张数据结构完全不同的表宏就废了。你当然可以用 Python 脚本去处理但对不擅长编程的人来说每次遇到新的 Excel 需求都要从零写脚本门槛又太高了。这时候引入 AI MCP 的思路就很自然把“理解需求”交给 AI把“执行操作”交给工具把“处理流程”沉淀成一套可随时调用的服务。1.2 MCP 是什么AI 世界的“万能插座”如果你第一次接触 MCP可以用一个类比来理解它就像 USB-C 接口。过去你想给各种设备充电、传数据、连显示器得准备一堆不同的线材和转接头USB-C 统一了物理接口后一根线就能解决大部分问题。MCP 就是 AI 应用和外部工具之间的那根“标准线”。在没有 MCP 之前大模型接入工具的方式是很混乱的。每个模型厂有自己的一套 function calling 规范每个应用接入一个第三方服务都要单独写一套对接逻辑。MCP 把这个环节标准化了工具提供方只要按照 MCP 协议封装成一个 Server任何支持 MCP 的客户端都能直接调用。对你这种想自己动手做工具的人来说最大的好处是——你辛苦写出来的 Excel 工具理论上可以在多个支持 MCP 的客户端里复用而不是绑定在某一个平台上。MCP 里的核心概念并不多弄清楚三个就够了Server 是提供能力的服务端比如你的 Excel 工具就运行在 Server 里Client 是发起请求的客户端比如你日常使用的 AI 助手Tool 是 Server 暴露给模型的功能单元比如“读取 Excel”“写入 Excel”“生成图表”。模型根据用户的自然语言描述动态决定调用哪个工具、传什么参数。1.3 选 Excel 作为练手项目的四个理由第一个理由是价值可见。做完一个 Excel MCP你能立刻在真实工作里用上效果很直观说一句话AI 帮你把表格整理好这种反馈比写一个“hello world”强烈得多。第二个理由是技术难度刚好。MCP 本身不难核心就是把函数暴露出去。但难点在于工具的边界设计、参数的合理规划、异常情况的处理——这些经验和问题在 Excel 场景里都能遇到又不会太复杂。第三个理由是周边生态成熟。Python 处理 Excel 的开源库非常多openpyxl、pandas、xlwings 都很成熟你不需要从零造轮子。我这次选择的是 Python openpyxl pandas 组合轻量、文档全、遇到问题好搜。第四个理由是场景可复制。Excel 只是第一个你跑通了这个链路后稍微改一改函数就能把邮件处理、PDF 文档整理、网页信息采集全部接入进来。我自己的项目路径就是这么走的先啃下 Excel再横向复制到别的工具上后面越做越顺。2. 环境准备与整体设计思路2.1 开发环境Python uv MCP SDK在开始动手之前先把环境搭起来。我用的主力语言是 Python版本最好在 3.10 以上因为 MCP 官方 SDK 对较新的语法特性有依赖。如果本机还没有一个干净的 Python 环境我强烈建议用 uv 来管理而不是直接往系统环境里装一堆依赖。uv 这个工具用起来很像 npm 的替代品创建虚拟环境、锁定依赖版本、执行脚本都非常顺手后面调试 MCP Server 时也不容易把环境搞乱。安装完 uv 后创建项目目录在里面建一个虚拟环境uv venv .venv source .venv/bin/activate然后安装核心依赖uv add mcp[cli] openpyxl pandas这里的mcp[cli]会带上命令行工具方便我们后面直接跑 MCP Inspector 来做调试。openpyxl 负责读写 xlsx 文件pandas 负责更复杂的数据聚合分析。这里有个小提示如果你只需要读写简单的表格只装 openpyxl 就够了pandas 更大也更重。我选择装上是因为后面做“按分组求和”这类操作时pandas 的 groupby 几个字就能搞定比手写循环优雅得多。2.2 先想清楚架构Server 长什么样很多第一次写 MCP 的人会犯一个错误上来就写代码写到一半发现不知道工具该怎么划分。我的建议是先想清楚你要暴露哪些“能力”再动手。所谓暴露能力就是定义 Tool 的粒度。我在设计 Excel MCP Server 时第一版把所有操作都拆成了很细的工具比如read_cell、write_cell、get_sheet_names。结果实际用起来体验很差因为 AI 模型在对话中处理复杂任务时会拆成很多步每步调用一个小工具来回交互几十次又慢又容易出错。后来我改成了面向任务的粗粒度工具比如read_excel一次读取一个范围内所有数据group_and_aggregate直接完成分组汇总generate_chart直接生成图表插入工作表。模型调用一个工具就能完成一大段操作效果立刻好了很多。这段时间我的体会是工具的粒度决定了 AI 编排的顺畅度。粒度太细模型容易在中间步骤迷路粒度适中模型能一次性拿到足够信息做判断。2.3 FastMCP 带来的开发体验提升我这次用了mcp.server.fastmcp.FastMCP这是官方 SDK 里一个偏高层封装的入口。相比直接用底层 Primitive 去写FastMCP 把“注册工具、声明 Schema、管理进程通信”这些繁琐工作都包掉了。你只需要定义普通的 Python 函数然后在上面加一个装饰器函数就能自动变成一个 MCP 工具。FastMCP 还有一个很省心的地方它会根据函数的类型注解自动推断参数描述。比如函数里写path: str它就知道 tool 的参数path是字符串类型如果你在 docstring 里写一句说明它也会把这句话作为工具的 description 传给模型。这意味着你不需要手动维护一份 JSON Schema开发速度能快不少。3. 从零实现一个可用的 Excel MCP Server3.1 第一个工具读取 Excel 并返回结构化数据我们先写最基础的能力——读取一个 Excel 文件的内容。这个工具是所有后续工作的前提因为 AI 要“看到”表格里有什么才能决定下一步怎么做。import json from pathlib import Path from mcp.server.fastmcp import FastMCP import openpyxl mcp FastMCP(Excel Helper) mcp.tool() def read_excel(path: str, sheet: str None, start_row: int 1, max_rows: int 50) - str: 读取 Excel 文件指定工作表的内容返回二维数组的 JSON 字符串。 Args: path: Excel 文件的完整路径。 sheet: 工作表名称缺省时读取第一个可见工作表。 start_row: 从第几行开始读取默认第 1 行通常为表头。 max_rows: 最多读取多少行防止返回数据量过大。 wb openpyxl.load_workbook(path, data_onlyTrue, read_onlyTrue) ws wb[sheet] if sheet else wb.active rows [] for row in ws.iter_rows(min_rowstart_row, max_rowstart_row max_rows - 1, values_onlyTrue): cleaned [ if v is None else str(v) for v in row] rows.append(cleaned) return json.dumps(rows, ensure_asciiFalse)注意两个细节。第一data_onlyTrue是很重要的参数它让 openpyxl 读取公式的计算结果而不是公式本身。如果你不设置这个读到的单元格里可能是SUM(A1:A10)这样的字符串对 AI 理解数据毫无价值。第二我用read_onlyTrue这个模式占内存很小处理大一点的表格不会卡死。max_rows这个参数也是我在实践过程中加上的。一开始没限制行数AI 读一张 10 万行的表时直接把返回数据撑爆了模型上下文根本放不下运行直接失败。后来改成默认只读 50 行并在 docstring 里告诉模型“默认最多读取 50 行可使用 max_rows 扩大范围”效果就稳定了。核心思路是不要让 AI 一次性背下整本字典让它按需翻页。3.2 第二个工具分组汇总和写入结果有“读”自然要有“写”。但光写一个write_cell意义不大我设计了一个更实用的组合工具根据指定列分组对值列求和然后把结果直接写到一个新工作表里。import pandas as pd mcp.tool() def group_sum_to_sheet(path: str, group_col: str, value_col: str) - str: 读取 Excel按指定列分组对另一列求和并把结果写入新工作表 汇总。 Args: path: Excel 文件的完整路径。 group_col: 用作分组依据的列名例如 地区。 value_col: 需要求和的数值列名例如 销售额。 df pd.read_excel(path) result df.groupby(group_col, as_indexFalse)[value_col].sum() out_path Path(path) with pd.ExcelWriter(out_path, engineopenpyxl, modea, if_sheet_existsreplace) as writer: result.to_excel(writer, sheet_name汇总, indexFalse) return f已生成汇总结果共 {len(result)} 行写入工作表 汇总。这里用modea是把结果追加到现有文件里。如果你需要保留原表和汇总表在同一个工作簿里这个模式很合适如果只想单独输出一个结果文件把path换成新路径即可。还有一个容易被忽略的点在真实场景里输入列名要和表格实际列名严格一致否则 pandas 会抛出 KeyError。我在写工具说明时专门加了“group_col 需要是表格中实际存在的列名”这一句让模型在调用前先去读表头而不是凭空猜列名。这一步看似多余实测下来能把失败率降低一大截。3.3 第三个工具生成图表并插入指定位置数据只有变成图表才更有说服力。openpyxl 本身支持在 xlsx 里插入图表我把它封装成了一个工具。mcp.tool() def generate_chart(path: str, sheet: str, min_col: int, max_col: int, max_row: int, chart_type: str bar) - str: 基于指定数据区域生成图表并插入工作表的右侧空白区域。 Args: path: Excel 文件的完整路径。 sheet: 要读取数据并插入图表的工作表名称。 min_col: 数据区域最小列号。 max_col: 数据区域最大列号。 max_row: 数据区域最大行号。 chart_type: 图表类型支持 bar / line / pie默认 bar。 wb openpyxl.load_workbook(path) ws wb[sheet] data openpyxl.chart.Reference(ws, min_colmin_col, min_row1, max_colmax_col, max_rowmax_row) if chart_type line: chart openpyxl.chart.LineChart() elif chart_type pie: chart openpyxl.chart.PieChart() else: chart openpyxl.chart.BarChart() chart.add_data(data, titles_from_dataTrue) ws.add_chart(chart, J2) wb.save(path) return f已生成 {chart_type} 图表插入到 {sheet} 的 J2 单元格位置。用同一个 Writer 循环跑三个工具先从read_excel读取原始数据再用group_sum_to_sheet生成汇总表最后用generate_chart基于汇总区域绘图整条链路就跑通了。这里我默认把图表放在 J2 位置是因为大部分表格的内容区域不会占用太宽的列如果你的表特别宽可以再暴露一个anchor_cell参数。3.4 启动 Server 并连接客户端调试写完这三个工具后启动 Server 非常简单if __name__ __main__: mcp.run()默认是 stdio 传输方式也就是通过标准输入输出和客户端通信适合在本机运行。如果你想通过网络被远程客户端调用可以用mcp.run(transportstreamable-http)这样会起一个 HTTP 服务客户端通过 URL 访问。实际操作中大多数首次开发场景用 stdio 就够了环境更简单出了问题好排查。连接客户端调试时我首推官方工具 MCP Inspectornpx modelcontextprotocol/inspector python excel_mcp_server.py运行后会起一个本地调试面板你可以直接在面板里列出工具、传入参数、查看返回结果非常直观。我每次开发新工具都会先在这里验证一遍确认工具本身没问题再接 AI 客户端做端到端测试。如果你用的是桌面类 MCP 客户端一般需要在客户端的配置文件里注册这个 Server。以 JSON 类型的配置为例大致是这样{ mcpServers: { excel-helper: { command: python, args: [/absolute/path/to/excel_mcp_server.py] } } }这里的 command 必须是绝对路径下的可执行 Pythonargs 也必须指向脚本的绝对路径。很多第一次跑不起来的案例都是因为用了相对路径或者没激活虚拟环境导致客户端找不到解释器。一个稳妥的做法是先which python查看当前虚拟环境 Python 的绝对路径然后在配置里填那个绝对路径。4. 三个真实工作流验证 AI 重构后的效率提升4.1 场景一销售数据自动汇总先拿一个常见的需求来测试有一个销售明细表包含日期、地区、销售员、销售额四列总计几千行。传统做法是你打开 Excel手动筛选地区或者用 SUMIF 函数一列一列地写公式用 AI MCP 就变成了一段自然语言对话“请读取这个文件按地区汇总销售额把结果写到新表里。”模型会根据工具描述自动调用read_excel先看结构再调用group_sum_to_sheet传入 group_col 为“地区”value_col 为“销售额”。整个过程在几十秒内完成而且不会因为手滑选错区域而出错。我可以反复用不同的字段问问题“按销售员汇总”“每个区域的订单数量是多少”模型会自动组合工具完成不同维度的分析。4.2 场景二脏数据清洗与格式修复现实中的 Excel 表格远比理想状态脏有空值、有多余空格、日期格式不一致、还有“1,234”这种带着千分位的文本。如果人工清洗光是“把数字当作文本存储”这个问题就能让人崩溃。我封装了一个清洗工具去掉首尾空格把纯数字字符串转成数字把不能识别的空单元格统一填成“缺失”。mcp.tool() def clean_sheet(path: str, sheet: str) - str: 清洗指定工作表中的常见脏数据并保存副本。 清洗规则 - 所有单元格去除首尾空格 - N/A、null、空字符串统一变为 None - 纯数字字符串转为浮点数 wb openpyxl.load_workbook(path, data_onlyTrue) ws wb[sheet] for row in ws.iter_rows(): for cell in row: val cell.value if val is None: continue if isinstance(val, str): val val.strip() if val.lower() in (n/a, null, ): val None else: try: val float(val) except ValueError: pass cell.value val out str(Path(path).with_name(Path(path).stem _cleaned.xlsx)) wb.save(out) return f清洗完成结果已保存为 {out}实际操作中我不建议直接覆盖原文件而是保存成带_cleaned后缀的新文件。原因很简单清洗规则不可能百分百正确如果 AI 理解错了需求把原始数据覆盖掉恢复成本太高。保留副本随时能回退。4.3 场景三从 Markdown 表格转换生成正式 Excel还有一个我经常遇到的场景在和 AI 对话过程中它直接给我输出一个 Markdown 格式的表格比如“给你的设备资产清单如下”。但 Markdown 表格在正式汇报里不实用我要的是格式良好的 xlsx 文件。这个需求也可以通过一个专用工具来做读取一段 Markdown 表格文本解析后写入 Excel。这个工具可以把“聊天记录里的表格数据”直接变成可编辑的 Excel 工作簿以后开会前整理例会数据非常方便。我在实践后总结出一个心得MCP 工具最好不要只映射“单个 Excel 操作”而要紧贴“用户的实际任务”。用户想要的不是“读文件”而是“把聊天里的表格落成一份正式的 Excel”。4.4 工作流重构后的整体效率对比这几件事如果放在以前我的操作时间大约是数据汇总 15~20 分钟脏数据清洗 20~40 分钟Markdown 转 Excel 至少要手动复制粘贴再调格式10 分钟左右。用 MCP 工具链跑下来大多数场景在 1 分钟内能完成且操作越是重复、数据量越大节省时间的效果就越明显。更重要的变化是认知层面的以前我面对一份新 Excel 是“打开软件开始点”现在我面对它时第一反应是“我可以怎么描述这个需求让模型自动处理”。这种从“手动操作”到“任务编排”的思维转变才是工作流重构的核心价值。5. 常见问题与排查技巧实录5.1 “工具加载不出来”怎么查第一次配置 MCP Server 时最常见的失败现象是客户端能识别到 Server但工具列表一直是空的或者调用时报错“tool not found”。我的排查顺序一般是固定的先用命令行直接跑一次python excel_mcp_server.py看有没有报语法错误或依赖错误再用 MCP Inspector 以同样的启动方式加载如果能列出工具说明 Server 本身没问题问题出在客户端的配置上。如果 Inspector 里也看不到工具优先看日志——很多时候是某个依赖没装上导入模块时抛了异常。还有一个小坑是环境问题。你在终端里激活了虚拟环境命令能正常跑但客户端配置里的command直接填的是“python”它可能指向了系统环境而不是虚拟环境。解决方式很简单配置里写command为虚拟环境里 Python 的绝对路径或者用一个 shell 脚本来激活环境后再启动。5.2 Excel 读写中的经典坑点处理 Excel 时有两类经典问题值得单独说。第一类是xls 和 xlsx 的兼容性问题。openpyxl 只支持 xlsx不支持老版的 xls。如果碰到老文件要么用xlrd库读取旧格式要么提示用户先另存为 xlsx。我在工具说明里特意写了一句“仅支持 xlsx 格式”省掉了很多无谓的尝试。第二类是文件占用问题。如果你在 Excel 软件里正开着这张表Python 脚本去写入时就会报权限错误因为 Windows 上 Excel 默认会把文件锁住。我在封装写入工具时会在写入前强行要求先关闭文件或者在 try except 里捕获 PermissionError返回一句“文件被占用请先关闭后再试”。这个细节虽然简单但能避免很多莫名其妙的失败。还有一类容易被忽略的是日期序列化。openpyxl 读取到的日期是 Python 的datetime对象直接json.dumps会报错。我在返回数据之前会把所有单元格统一转成字符串虽然这样损失了类型信息但对 AI 理解内容没有影响也让传输格式稳定。5.3 数据量太大导致 AI“失忆”的处理思路还有一个让我思考了很久的问题模型的上下文窗口是有限的不能把所有数据一股脑丢给它。遇到一张几万行的表时如果工具把全部内容都返回模型很容易遗漏重要信息甚至直接拒绝处理。我的处理方式是分层设计第一层工具只返回前 N 行预览数据让 AI 了解表结构第二层提供带筛选或聚合的工具让 AI 基于条件只提取需要的部分第三层是专门的汇总工具直接把计算结果返回给 AI而不是把原始数据透传。这一整套“先预览、再筛选、后聚合”的思路是整个 Excel MCP Server 里我认为最有价值的设计。提示如果你希望这个 Server 后续能被更多客户端复用尽量保持工具输入输出都以 JSON 字符串为主避免依赖客户端的特殊类型。JSON 是各类 MCP 客户端支持最好的格式。6. 从 Excel 开始把 MCP 能力复制到更多场景跑通第一个 Excel MCP Server 后你会发现这个开发流程具有很强的“复制性”。我现在手里已经有几个基于同一套思路扩展出来的工具一个用于批量整理 PDF 文档信息一个定时抓取网页表格并写入 Excel还有一个是把日常巡检记录自动生成日报。每个工具都是同样的套路——把任务拆成几个粗粒度的 Tool用 FastMCP 暴露再通过客户端自然语言编排。如果要把这份经验总结成一句话MCP 开发的重点从来不是协议本身而是你对任务的拆解能力。协议帮你解决了通信和调用的标准化问题但真正让 AI “好用”的是你把复杂任务拆成了哪些工具、每个工具的输入输出设计是否合理、异常处理是否完备。这些能力没有捷径只能通过真实项目去积累。我在实际做这个项目的过程中有一个体会特别深不要追求第一次就把工具做得多完美先跑通一个最小的闭环更重要。哪怕你只有一个read_excel工具先把 Server 跑起来接到客户端里自然语言问一句“这个表里有哪些列”看到模型能准确回答出来那种“打通了”的感觉会给你继续做下去的信心。后面再遇到新需求你只需要往 Server 里加函数、加装饰器功能就自然扩展出去了这个正反馈循环会推着你越走越远。