前阵子把Agent系列推进到第8阶段的时候一个绕不开的技术点终于摆到了台面上——MCP Server。做Agent开发的朋友应该都有同感模型能力再强如果接不上你的业务数据、调不动你内部的操作接口它就是一只没有手的大脑。而MCP Server恰恰就是这双手。这篇实战记录我围绕Agent系列8.4-MCP-Server开发实战这个主题把从协议理解、工具设计、代码落地到上线排错的完整过程写出来希望能给正在啃Agent开发的学习者、或者已经在用Claude Desktop/Cursor但总觉得工具接入别扭的开发者一些直接能用的参考。我之前遇到过很多同学问Agent框架那么多为什么不直接用现成的插件工具非要自己写Server答案很简单——现成插件解决的是通用工具的场景一旦你要把公司内部业务系统、私有数据、自定义流程接进来就必须让Agent以一种标准化协议去触达这些能力而MCP就是目前生态最认可的答案。这篇文章用的技术栈是Python因为MCP官方Python SDK成熟度最高而且对大多数业务系统来说接入成本最低。全程不讲虚的只讲我在这次实战里验证过的东西。1. 先想清楚MCP Server在Agent体系里到底扮演什么角色1.1 一句话讲明白MCP是什么MCP全称Model Context Protocol模型上下文协议。名字听起来很高深本质就是一套标准插座它规定了AI应用Host怎么发现工具、怎么调用工具、工具执行结果怎么返回。类比一下你的电脑要接各种外设以前每个厂商接口都不一样后来统一成USB-CMCP就是AI应用界的USB-C。在MCP的架构里有三方角色协同工作角色职责类比Host运行大模型的主应用负责判断要不要调用工具指挥官Client维护与Server的连接、管理会话状态传令兵Server暴露工具/资源/提示模板执行实际操作现场执行队我第一次上手时犯过一个认知错误以为Server是服务就必须跑在远程。实际上MCP支持两种传输方式stdio本地进程间通信和HTTP方式跨网络调用。开发初期用stdio最省事——你的Server就是一个普通Python进程客户端直接拉起它通过标准输入输出对话不需要管端口、鉴权这些事调试体验非常接近普通命令行程序。1.2 为什么工具边界要先于代码设计这次实战给我最大的教训是写工具函数的代码花不了多少时间真正耗时的是想清楚哪些能力该暴露给Agent。很多人第一步就翻车——把内部管理接口一股脑全部注册成工具大模型随机调用出了问题才后悔。我自己定的工具边界原则有三条只暴露幂等、可重放的操作。查询、汇总、生成报告这类重复执行不影响结果的接口优先接入。转账、删除、批量修改这类操作我一般不做成Tool或者必须在工具内部叠加二次确认逻辑。每个工具的动作面要窄。宁可有20个细粒度的工具也不要3个参数巨多的大工具。大模型在复杂Schema面前容易选错参数名、漏传必填项工具越聚焦调用成功率越高。私有数据尽量通过只读查询暴露不要用导出文件再让Agent解析的方式。比如做一个query_orders工具让Agent自己组织查询条件比开放一个文件导出接口安全得多权限边界清晰还方便审计。这里还有个容易被忽略的点工具的description是写给大模型看的不是写给文档管理员看的。描述里必须包含什么时候用这个工具参数的含义一个典型调用示例。我在Series里反复验证过描述写得越细Agent的选工具准确率提升越明显这一点怎么强调都不过分。2. 核心概念与工具设计决定你的Server能不能被Agent用好2.1 理解Tool、Resource、Prompt三大能力一个MCP Server可以暴露三类能力搞清楚这三者的区别是设计Server的第一步。Tool功能性操作由大模型根据用户意图自动决定是否调用。比如查天气统计订单金额。Tool有输入参数Schema执行结果以文本或结构化数据返回。这是Agent的手。Resource只读数据源用URI标识类似一个只读文件系统。比如一个配置文件、一个API返回的JSON、一段日志内容。模型可以直接读取这些内容作为上下文。这是Agent的眼睛。Prompt预定义的提示模板面向用户手动触发或半自动场景。比如一个周报生成器用户填几个变量就能输出固定模板的周报。这是Agent的模板记忆。我刚接触MCP时经常把Resource和Tool搞混。后来总结了一个判断标准如果数据被加工后再返回就用Tool如果数据原样读取给模型当上下文就用Resource。举个例子读取一个固定的Excel模板做后续分析用Resource根据参数动态计算销售额用Tool。按照这个标准划分Server的能力边界会清晰很多。2.2 工具命名、描述与参数Schema的实操要点工具名是大模型识别工具体系的标识符。虽然命名不直接影响推理效果但影响模型在候选工具中的发现率。我推荐的命名规则是动词_对象全小写下划线动词尽量避免语义含糊。get、query、fetch这类词在一个Server里只能选一个统一使用混用会导致模型在选工具时犹豫不决。参数Schema用的是JSON Schema标准这里有个非常关键的实践经验所有字段都要写description尤其是枚举值和可选字段。大模型靠文本理解参数你给一个status: string模型根本不知道传什么值你写成status: pending | paid | refunded模型就能做出正确选择。我把这条总结成一句话Schema即Prompt——参数定义写得越像一份说明书模型调用越准确。还有一个高频踩坑点布尔开关不要拆成两个工具不要用一个复合对象参数替代多个简单参数。比如create_order(customer_id, items, payment_method)一定优于create_order(payload_object)前者模型能理解每个字段的含义后者模型只能猜你的对象结构。2.3 底层协议看一眼心里更有底虽然用FastMCP不需要手写协议报文但我还是建议至少看一遍Client和Server之间的对话过程这对接下来的排错极有帮助。当Client启动Server后二者通过JSON-RPC交换消息。初始化阶段Client会发一条initialize请求Server返回支持的协议版本和自身能力。{jsonrpc: 2.0, id: 0, method: initialize, params: {protocolVersion: 2024-11-05, capabilities: {}, clientInfo: {name: test-client, version: 0.1.0}}}握手完成后Client会轮询工具列表这一步叫tools/list。真正调用时Client发送的是tools/call请求{jsonrpc: 2.0, id: 2, method: tools/call, params: {name: query_order_stats, arguments: {start_date: 2025-01-01, end_date: 2025-01-31}}}Server收到后执行对应函数把结果封装成TextContent返回。理解了这套报文当你看到工具没出现在列表里调用报错但客户端只显示超时这类问题时就可以顺着链路去排查是initialize没成功还是tools/list返回异常抑或是tools/call的执行环节抛了异常。这个排查顺序比盲目改代码高效得多。3. 从零实现跑通一个MCP Server的完整记录3.1 环境准备与SDK选型Python路线我这次用的是MCP官方Python SDK。安装很简单pip install mcp[cli]安装后建议顺手确认一下版本因为MCP的API演进非常快很多网上教程写的还是旧版写法直接抄会出现各种兼容问题。python -m mcp --version在正式开始之前把Python环境隔离好。我习惯用uv或venv建独立环境避免依赖互相污染。这个习惯在MCP调试阶段尤其重要——stdio模式下Client启动的Server子进程会继承当前环境变量环境混乱会导致Server明明起不来却查不到原因非常折腾。选型层面mcp库提供两套API低层Server API和高层FastMCP。我的建议是快速验证想法用FastMCP它用装饰器和类型标注就能声明工具代码量最少需要精细控制协议行为时再切回低层API。这次实战我主要展示FastMCP写法同时在关键位置说明底层机制方便你按需切换。3.2 核心代码实现与解析这节的目标是做一个订单查询MCP Server暴露两个工具按日期范围统计订单状态、按客户ID查询订单列表。代码如下from typing import Literal from mcp.server.fastmcp import FastMCP # 创建Server实例名字会显示在客户端的工具列表里 mcp FastMCP(order-helper) # Mock数据实际项目里替换成数据库或HTTP调用 MOCK_ORDERS [ {id: 1001, customer_id: C001, amount: 299.0, status: paid, date: 2025-01-05}, {id: 1002, customer_id: C002, amount: 159.0, status: pending, date: 2025-01-06}, {id: 1003, customer_id: C001, amount: 488.0, status: paid, date: 2025-01-07}, ] mcp.tool() def query_order_stats(start_date: str, end_date: str) - str: 按日期范围统计订单状态返回每种状态的数量和总金额。 stat: dict[str, int] {} total_amount 0.0 for item in MOCK_ORDERS: if start_date item[date] end_date: stat[item[status]] stat.get(item[status], 0) 1 total_amount item[amount] order_count sum(stat.values()) return f范围内订单 {order_count} 笔总金额 {total_amount:.2f}状态明细{stat} mcp.tool() def query_order_list(customer_id: str, status: Literal[paid, pending, refunded] | None None) - list[dict]: 根据客户ID查询订单列表可按状态过滤。 items [item for item in MOCK_ORDERS if item[customer_id] customer_id] if status: items [item for item in items if item[status] status] return items if __name__ __main__: mcp.run()几个细节值得展开说mcp.tool()装饰器会把函数的类型标注和docstring自动转换成MCP的Tool定义。所以docstring不是可选项它就是喂给模型的说明书写得越详细越好。返回值我统一用Python原生对象FastMCP会自动序列化成JSON。如果切到低层API就需要手动构造TextContent对象。示例里status用了Literal类型SDK会把它映射成JSON Schema的枚举字段比我手动写枚举更省力从源头避免Schema写错的风险。如果工具里需要查数据库、调HTTP接口直接在函数体里写就行。FastMCP不限制实现方式它只管协议层对接业务逻辑完全由你掌控。3.3 用客户端联调与stdout调试技巧代码写完后第一步验证是直接命令行启动python order_server.py启动后进程会卡住这其实是正常状态——它正在stdio上等待客户端握手。你可以用MCP官方CLI里的dev命令启动调试面板python -m mcp dev order_server.py这个命令会拉起一个本地调试服务在面板里能看到Server注册了哪些工具、手动输入参数触发调用、查看返回结果。到了这一步工具是否注册成功、Schema是否解析正确基本就能验证清楚。如果要把Server接进Claude Desktop需要在它的配置文件里声明。macOS的路径是~/Library/Application Support/Claude/claude_desktop_config.jsonWindows在%APPDATA%\Claude\claude_desktop_config.json。配置示例{ mcpServers: { order-helper: { command: python, args: [/absolute/path/to/order_server.py], env: {} } } }这里有一个我踩过的坑args里的路径必须是绝对路径相对路径在桌面应用的子进程工作目录里极不可靠。另一个坑是虚拟环境——如果你用了venvcommand一定要指向venv/bin/python不要贪图省事写python否则客户端拉起的是系统Python依赖找不到Server直接启动失败。联调阶段最容易让人抓狂的问题是Server明明没死客户端却报超时。这背后的机制是在stdio传输模式下Client通过Server的stdout读取返回数据。因此你在代码里用print()打印调试日志就会直接污染协议通道导致客户端解析出错。我第一次就因为这个在工具函数里加了一堆print结果调试面板上全是解析错误。正确的做法是日志统一走stderr。可以在启动时配置一个指向stderr的loggerimport logging import sys logging.basicConfig(streamsys.stderr, levellogging.INFO)这样业务日志出现在终端里但不会干扰协议通道。这个习惯养成之后调试MCP Server的幸福感会直线上升。3.4 从stdio迁移到HTTP方式什么时候做、怎么做开发验证阶段用stdio完全够用但一旦要接入多台机器或者做成共享服务就必须迁移到HTTP方式。MCP的Server端在FastMCP里切换传输方式非常顺滑if __name__ __main__: mcp.run(transportstreamable-http)迁移时要注意几个问题端口和鉴权需要自己实现或借助网关。官方SDK对HTTP模式的鉴权设计尚在演进现阶段建议在Server前面套一层网关做token校验后再转发。超时策略要调整。stdio模式下进程生命周期与Client绑定HTTP模式下Server常驻运行工具函数里的长业务操作必须考虑超时和并发。日志策略要改。HTTP模式下stderr不再自动呈现得接日志文件或日志收集服务方便事后排查。我的判断标准是只要Server的使用者超过一个客户端实例就优先HTTP方式。宁可前期多花半天做鉴权和部署也别在后期靠拷贝配置去凑合。4. 问题排查实录那些文档里没有的坑4.1 常见问题速查表把这段时间反复踩过的典型问题整理成一张速查表按出现频率排序现象原因解决方法Server启动后没有任何握手日志Client找不到可执行文件或路径错误检查command和args是否绝对路径先手动命令行启动验证调试面板显示工具列表为空装饰器没生效或进程异常退出确认mcp.run()被调用查看stderr输出调用返回Tool execution failed工具函数内业务代码抛异常函数内加try/except把异常转换成结构化错误信息返回中文结果乱码或被截断stdout编码问题或返回内容过大设置PYTHONIOENCODINGutf-8拆分大段返回内容客户端连接后一直loadingstdio被print输出污染排查所有print调用日志统一改走stderr报missing required参数缺失Schema必填字段太多模型没传全在描述中提供完整示例尽量精简必填字段中文乱码这个坑值得单独说一下。stdio通道默认继承父进程编码如果客户端环境不是UTF-8中文返回大概率乱码。我用了两招第一是在启动命令里配置环境变量PYTHONIOENCODINGutf-8第二是在工具函数内部统一把输出转成UTF-8字符串。第二种更稳妥因为环境变量不保证在所有启动方式下都生效。4.2 安全底线工具权限与审计MCP Server的本质是让大模型获得执行代码的通道权限设计必须从第一天就考虑否则越往后越难补。我给自己定的安全清单如下输入验证永远在Server端做不能依赖模型自觉。大模型可能被用户的prompt注入诱导去传非法参数所以每个工具函数都要做参数白名单校验不能只靠Schema。敏感操作必须叠加二次确认。MCP协议本身没有这套机制需要自己实现。我见过一种稳妥的做法把确认执行也设计成一个工具让模型先调用确认工具再去执行实际操作两步都记录在案。关键调用要写审计日志内容包括模型给出的原始参数、Server实际执行的逻辑、返回结果摘要。日志写到独立文件不要混在stderr里。后面排查Agent为什么做了一件事时这个日志就是唯一依据。Tool的描述里绝不能写内部信息比如数据库连接串、内网域名、密钥占位符。原因是工具描述会被发送给大模型API厂商这类信息等于直接通过API透传出去了。上线前的走查清单里必须加一条扫描所有Tool的description和参数名确认无敏感字段。这套安全清单看上去繁琐但真要出了事故每条都是救命稻草。Agent开发里能力越大责任越大这句话不是玩笑话。5. 接下来我想在这个Server上继续做的事5.1 缓存层与Resource扩展第一个想加的是缓存。当前的query_order_stats每次全量遍历数据数据量大了明显变慢。可以在Server进程内维护一个LRU缓存以参数为Key缓存时间控制在30秒左右。注意缓存只加在幂等查询类工具上写操作类工具绝对不能缓存。第二个想加的是Resource能力——把Server自身的关键状态暴露出去。比如最近10次工具调用的记录、当前运行的版本、加载的工具清单都可以通过Resource暴露给Agent。这样Agent在自我排查时能看到状态而不是被动等待错误消息。5.2 多Agent共享时的路由与权限思路当多个Agent需要共享同一个企业工具库时MCP Server这层会自然演进成一个统一网关不同Agent按照权限路由到不同的Tool集合。这一步牵扯到权限模型设计我不会直接用官方SDK硬上而是先在业务代码里做一层薄封装按Agent身份过滤工具列表。等官方鉴权方案成熟后再逐步迁移。在踩过这些坑之后我个人最大的体会是MCP Server的开发难度不在代码而在于工具边界、Schema描述和安全审计这三件事。这三件事想清楚了代码一天就能写完想不清楚上线后维护的每一天都在还债。希望这篇实战记录能帮你少踩一两个坑把精力留给真正有价值的设计。