最近在技术群里聊大模型应用几乎每次都会绕到同一个话题MCP 到底解决了什么很多人的疑问是——模型厂商已经提供了 Function Calling函数也能传参、能返回结果为什么还要搞一个 MCP 标准协议说实话我一开始也有同样的困惑。直到在一个实际项目里把同一个工具分别用 Function Calling 和 MCP 各接了一遍才真正清楚差距在哪。这篇博文就围绕这个问题把 MCP 的设计哲学拆开聊适合后端工程师、AI 应用开发者以及那些正在纠结“要不要上 MCP”的团队参考。1. Function Calling 的真实面孔它解决了什么又卡在哪里1.1 先捋清楚 Function Calling 到底在做什么Function Calling函数调用本质上是模型 API 提供的一种能力开发者在请求里定义一组函数签名模型在生成回答时如果判断需要外部信息或执行某个动作会输出一个结构化的调用请求包括函数名和参数而不是直接生成自然语言。应用侧收到这个请求后在业务系统里真正执行函数把结果以消息形式回传给模型模型再基于执行结果生成最终回复。打个比方Function Calling 就像你给一个实习生配了一台对讲机对讲机上贴了十个按钮每个按钮对应一个动作。实习生跟你说“我按了 3 号按钮”但你得提前把按钮一个个装好而且每换一个工作场景、每换一台对讲机都要重新装一遍。这套机制在小规模场景下很好用它是大模型从“只会说话”走向“能够动手”的关键一步。今天几乎所有主流模型厂商都支持类似的工具调用能力这一点不需要怀疑。真正的问题是Function Calling 只定义了一个“模型怎么把函数调用请求说出来”的契约至于函数在哪里、怎么被发现、怎么被组织、多个系统之间怎么协作它完全不管。随着业务复杂度的上升这三块缺失会越来越刺眼。1.2 三个最容易感知的痛点无状态、无发现、无边界第一个痛点是“无状态”。每次调用都是独立的请求-响应对函数执行结果不会自动沉淀到后续流程。你要自己维护上下文把上一次的工具结果拼进下一次的消息序列。多轮对话一长上下文就变得臃肿模型也容易在拼接过程中丢掉关键信息。我在实际项目中见过不少团队用消息数组硬扛最后不得不做各种截断和压缩。第二个痛点是“无发现”。调用方必须在每次请求里把全部函数定义列出来模型和调用方之间没有任何动态协商的机制。只有三五个固定函数时没问题但当你维护一个包含几十上百个工具的业务系统时每次请求都要把全部定义重新传输一遍Token 消耗会变成一个真实的成本项。举个例子一个稍微复杂点的工具定义动辄几百 Token40 个工具就是几万 Token这还没算多轮对话的重复发送。第三个痛点是“无边界”。函数的实现放在哪个服务、由谁部署、如何认证、如何做权限控制Function Calling 一概不过问。它只完成“模型要调用、应用来执行”这一动作。不同团队各自定义各自的函数格式Python 团队一套、Node.js 团队一套时间一长就形成一个个“方言孤岛”彼此之间完全无法复用。1.3 让问题浮出水面的典型场景我在一个内部运维辅助项目里接手过一套告警查询功能最初就是 Function Calling 方式。客户端的函数列表只有五个查询接口运行得挺稳。后来业务方要求接入自助巡检、日志检索、工单创建甚至物料库存查询函数列表膨胀到四十多个。问题立刻爆发一次请求要塞好几 KB 甚至十几 KB 的函数定义延迟和成本同步上升新增一个工具要重新发布客户端业务方急得直拍桌子各团队用不同语言写的函数外壳参数风格不统一模型经常在参数格式上出错。后来我们实在撑不住了把函数从客户端里抽出来做成一个独立的工具服务由客户端动态发现。这一步虽然是无意中做的但回头看其实就是被现实逼着走向了 MCP 的思路。这件事让我彻底想明白Function Calling 擅长解决的问题是“让模型能调用函数”但它没有回答“一套复杂工具生态应该如何被组织、暴露和复用”的问题。后者才是 MCP 真正要解的题。2. MCP 的背后与其说协议不如说一套会话模型2.1 从“函数”到“客户端-服务器”MCP 的整体轮廓MCPModel Context Protocol是模型与外部工具、数据源进行标准化交互的一种开放协议。注意它不是某一个厂商的 SDK也不是一个框架而是一套基于 JSON-RPC 2.0 的通信约定核心思想是把“函数”提升为“服务”。理解了这个转变就理解了一半的 MCP。我常用一个类比MCP 之于 AI 工具生态就像 USB-C 之于外设。USB-C 只规定物理接口和通信规范至于你接的是硬盘、显示器还是充电器由设备自己的驱动和固件实现。MCP 规定的也是“模型侧和工具侧之间的接口规范”工具内部的具体逻辑完全由服务方自己实现。MCP 的标准角色有三个Server 是提供能力的一方可以暴露工具、资源和提示词Client 是在 Host 内部与 Server 建立连接的连接器Host 是承载整个交互流程的宿主比如桌面客户端、IDE、各种智能体框架。这里有个容易混淆的点Host 和 Client 到底什么关系一句话Host 是用户面对的产品Client 是 Host 内部专门负责某一条工具连接的组件。这个分层让一套 Host 可以同时连接多个不同来源的 Server每个 Server 各自维护生命周期和数据互不干扰。2.2 JSON-RPC 之上的三大原语工具、资源、提示词MCP 把能力抽象成三类这是它跟 Function Calling 拉开差距的关键。第一类是工具Tools表示可控的动作比如执行 SQL、创建工单、调用外部 API语义上和 Function Calling 接近但工具是在 Server 上动态发现而不是写死在客户端请求里。第二类是资源Resources表示可读的数据比如文件内容、数据库查询结果、监控指标。客户端通过 URI 读取资源资源更新时可以推通知。第三类是提示词Prompts表示可复用的提示模板用于引导模型按既定模式完成任务比如“生成周报”或“按模板审核变更”。为什么这三类缺一不可因为一个完整的智能体不应该只会调用动作它还需要能够“查看”数据获取上下文以及“套用模式”来规范输出。Function Calling 只覆盖了“动作”这一类所以很多复杂任务做起来很别扭。举个例子你要让模型分析一份服务器日志Function Calling 只能让它把日志内容作为字符串参数传进函数日志一大就超出上下文限制而 MCP 的资源可以直接给模型一个可读取的 URI按需拉取避免了无意义的搬运。工具和资源之间的边界也不是死的。同一个后端能力既可以通过资源暴露为只读数据也可以通过工具暴露为可写动作。设计时要想清楚这个能力的核心语义是什么——是数据还是操作。我见过一些团队把查询接口做成工具导致模型频繁用工具去拉一整张大表既浪费时间又烧 Token正确做法应该是把这种高频只读查询设计成资源。2.3 一次性握手与能力协商为什么 MCP 更省对比 Function Calling 每次请求都带全量函数定义的做法MCP 把发现和调用拆成了两个阶段从结构上就解决了“工具定义膨胀”的问题。第一阶段是初始化握手。Client 向 Server 发送initialize请求带上协议版本和客户端能力说明Server 返回协议版本、服务端能力和服务信息随后 Client 发送notifications/initialized通知双方进入就绪状态。这一阶段回答的是“这个 Server 是什么、支持哪些协议能力”的问题。第二阶段是动态发现。Client 可以随时调用tools/list、resources/list、prompts/list等接口获取能力清单。清单不会塞进每一次模型请求里而是缓存在 Client 侧按需更新。关键点在这里在具体实现中MCP Client 会把发现到的工具转换成目标模型可以理解的 Function Calling 格式再走模型原生调用链路。也就是说MCP 和 Function Calling 并不是非此即彼的替代关系在很多架构里MCP Client 就是用来生成高质量工具配置的前置层。想明白这一点你就不会再纠结“到底选哪个”而是会考虑“在什么层级用哪一个”。2.4 设计哲学标准化“接口”而非“实现”前面说的是 MCP 是什么、怎么工作真正值得琢磨的是它背后的选择逻辑。第一MCP 选择定义“交互协议”而不是“API 规范”。它不规定工具用什么语言实现、数据存哪里任何实现了 JSON-RPC 消息交换的服务都可以成为 Server。约定的是双方的通信方式而不是业务实现方式这样既保住了生态的多样性又保证了互操作性。第二MCP 把“上下文”作为一等公民。协议名字里特意带上 Context意味着它着眼的不只是函数调用而是模型获取上下文的全过程。模型通过资源了解世界通过工具改变世界通过提示词规范对话方式三者合起来才是完整的上下文。设计者很清楚真正制约智能体的不是“能不能调用”而是“有没有足够的、结构化的上下文”。第三面向生态而非面向单点。单一 Function Calling 是模型 API 里的一个参数槽位跟着某个厂商的版本走MCP 是一个开放标准任何团队都能实现自己的 Server。现在能搜到的 Server 五花八门有做浏览器自动化的有接设计工具的有接安全测试工具的也有接音视频处理和 PLC 工程的。这说明 MCP 的目标是让所有人都往同一个接口上接入而不是围绕某一家的实现转。3. 协议拆解从头到尾走一遍 MCP 的交互流程3.1 完整的一次生命周期一个 MCP 连接的生命周期大致是创建 - 初始化 - 就绪 - 运行 - 关闭。整个生命周期里初始化是最容易出问题的环节。流程是这样的Client 建立传输通道可能是 stdio 也可以是 Streamable HTTP然后 Client 发送initialize请求附上协议版本和客户端能力Server 返回InitializeResult包含服务端信息、支持的协议版本和能力声明Client 再发送notifications/initialized通知确认初始化结束。完成这套握手之后双方才开始正常的工具调用和资源读取。这里有个最常见的误操作没有等待notifications/initialized就发送tools/list或tools/call。部分实现比较宽容会自动处理但严格按协议讲未完成初始化的连接发出的请求Server 是可以拒绝的。我在自定义 Server 里对非法时序直接返回错误并打日志结果帮客户端暴露了不少时序 bug。另一个容易忽视的点是协议版本协商Client 和 Server 可能支持不同版本initialize阶段会把双方的能力交集找出来后续功能必须在这个交集内使用。3.2 工具的发现与调用消息层级细看拿工具发现来说Client 发送{ jsonrpc: 2.0, method: tools/list, id: 1, params: {} }Server 返回{ jsonrpc: 2.0, id: 1, result: { tools: [ { name: query_alert, description: 查询告警信息可按级别和关键字过滤, inputSchema: { type: object, properties: { level: {type: string, enum: [info, warning, critical]}, keyword: {type: string} }, required: [] } } ] } }注意这里的inputSchema用的是 JSON Schema不是某个厂商私有的参数格式。这是 MCP 能被多种客户端复用的原因之一一切的边界都落到标准 JSON Schema 上客户端适配层只需要把这份 Schema 转换成目标模型的 Function Calling 参数即可。工具描述字段description也至关重要模型的工具选择很大程度上依赖这段自然语言描述。再看tools/call{ jsonrpc: 2.0, method: tools/call, id: 2, params: { name: query_alert, arguments: { level: critical, keyword: CPU } } }Server 返回结果有两种形态一种是完成结果包含多个content块每个块有type常见的是text也支持image等类型另一种是进度更新适合长耗时任务向客户端持续回报进度。返回结构里还允许带isError标志区分业务错误和协议错误。我特别欣赏这种设计业务上的“没查到数据”和协议上的“参数格式错误”是两回事模型可以分别处理。3.3 传输层stdio 与 Streamable HTTP 的选择逻辑MCP 的传输层经历过演进早期支持 stdio 和 HTTPSSE后来社区合并出了 Streamable HTTP 方案把普通 HTTP 请求和 SSE 响应收到一个通道里。今天官方推荐的就是两个stdio 和 Streamable HTTP。stdio 适合本地场景。Server 作为子进程被客户端拉起通过标准输入输出通信没有端口、网络配置、认证这些额外工作。对本地工具来说权限模型天然贴近当前操作系统用户简单直接。缺点很明显不能跨机器、不能服务多客户端。Streamable HTTP 则适合远程部署Server 作为 HTTP 服务客户端通过 URL 访问。选择时先问自己一个问题工具是跑在用户本地的还是集中部署在服务端的本地优先 stdio远程必须走 HTTP。远程模式下要特别注意几点URL 暴露在客户端的配置文件里意味着必须有访问控制Server 要处理并发请求长连接需要心跳或者空闲超时策略。我在一些项目里见过混合做法本地智能体通过 stdio 连接本地 MCP ServerServer 内部再去访问远程 API敏感凭据留在服务端不落到用户终端。这个模式的优点是既享受了 stdio 的简单性又把安全边界控制在了服务端。4. 实操半小时搭一个可用的 MCP Server 并接入客户端4.1 最小实现一个“开发辅助”的 MCP Server我用 FastMCP 的 Python SDK 写过最小实现包含两个工具和一条资源。安装命令就一条pip install mcp[cli]核心代码如下from mcp.server.fastmcp import FastMCP mcp FastMCP(dev-helper) mcp.tool() def calc_work_hours(start: str, end: str) - str: 根据开始时间和结束时间计算工作时长小时。时间格式为 HH:MM。 from datetime import datetime fmt %H:%M t1 datetime.strptime(start, fmt) t2 datetime.strptime(end, fmt) if t2 t1: t2 t2.replace(dayt2.day 1) return f{round((t2 - t1).total_seconds() / 3600, 2)} 小时 mcp.tool() def best_practice(topic: str) - str: 针对开发主题返回一条最佳实践建议。 rules { api: 接口稳定优先先冻结契约再并行开发。, auth: 认证尽量走标准流程不要自研校验逻辑。, } return rules.get(topic, f关于 {topic} 的建议先写测试再写实现。) mcp.resource(dev://now) def now_time() - str: 当前服务器时间用于上下文校准。 from datetime import datetime return datetime.now().isoformat() if __name__ __main__: mcp.run(transportstdio)这段代码已经能演示 MCP 的核心能力两个工具对应“动作”一条资源对应“可读数据”。FastMCP 会把mcp.tool()下面装饰器的 docstring 自动提取为工具描述所以写描述就是写 docstring别偷懒。我见过很多工具调用失败的案例最后排查下来都是描述含糊、模型猜不到这个工具应该在什么时候用。描述里如果可能尽量带上使用场景、参数格式、返回值示例。4.2 让客户端真正连上这个 Server本地调试时最简单的办法是用 stdio 方式直接拉起这个 Python 脚本。在支持 MCP 的客户端里添加一条 stdio 配置命令指向带 Python 环境的执行器python /path/to/dev_helper.py部分新版本客户端提供命令行管理 MCP 连接比如claude mcp add dev-helper -- python /path/to/dev_helper.py如果 Server 走远程就换成一条 HTTP 地址claude mcp add dev-helper --transport http http://your-host:8000/mcp用 Python 实现远程版本也很快把 FastMCP 的启动方式改成transporthttp即可SDK 内置了 Streamable HTTP 实现。具体路径以你的 Server 实现为准有的框架默认挂在/mcp有的挂在其他根路径。远程模式必须处理认证和端口暴露不要在裸 HTTP 上暴露管理类工具这是最基本的底线。4.3 调试工具的辅助Inspector 与日志MCP 社区提供了官方 Inspector可以像图形界面一样浏览 Server 暴露出的工具、资源并手动发起调用npx modelcontextprotocol/inspector它会让你选择以 stdio 还是 HTTP 方式连接到目标 Server然后在一个网页界面里查看工具列表、填写参数、发起调用、观察返回值。我习惯在 Server 里开启 debug 级别的日志把传输层消息打印出来看。很多时候排查问题不需要猜模型在想什么直接看协议层消息就够了是哪一步卡住、返回了什么错误、参数序列化后是什么样子一目了然。5. 常见问题与避坑实录5.1 超时与重试最常见的三个错误第一类问题客户端超时。默认超时往往在几十秒量级如果你的 Server 是启动很慢的 Python 进程或者某个工具内部做了长时间的外部网络调用很容易触发超时。解决思路不是盲目调大超时时间而是区分工具类型快速读操作应该保证百毫秒级响应长耗时任务设计成“提交任务 查询状态”的模式而不是让模型同步等待。一个小技巧是确保 Server 对空闲探测ping及时响应不要因为某个主线程被阻塞而导致整个进程对 ping 无应答。第二类问题传输方式不匹配。用 stdio 配置去连远程 HTTP 地址或者反过来在远程部署时监听 stdin都会导致连接建立失败或握手超时。排查时先确认配置里的 transport 参数和实际 Server 类型一致。第三类问题参数 Schema 写得太含糊。模型填充参数出错时不要只怪模型。把inputSchema里的字段约束写清楚加上description、enum、format甚至示例值。我给calc_work_hours的字段加了示例格式后调用成功率肉眼可见地提升。工具描述和字段描述是模型正确调用的前提这部分投入的每一分钟都是值得的。5.2 何时用 Function Calling何时上 MCP一个实用的判断标准如果智能体只需要调用三五个内部函数团队不大发布节奏快直接用 Function Calling 就够了引入 MCP 是额外的一层成本。如果工具数量会持续增长、需要多个客户端复用、或者工具要独立开发和独立发布那 MCP 的收益就体现出来了。服务方维护一份实现多个客户端共享不再为每个客户端单独适配。如果产品形态是“给用户提供一个可扩展的工具市场”MCP 几乎就是必选项。每个第三方工具打包成一个 Server用户安装即用客户端无需为每个工具发版。这个选择不是技术洁癖的问题而是成本与杠杆的取舍。5.3 安全与作用域别把整套后端直接暴露给模型MCP 让工具接入变得容易也带来了新的安全边界。最重要的注意事项不要在 Server 里暴露超出模型任务所需范围的权限。一个只用于查询告警的 Server就不要顺手把删除接口也暴露成工具。模型的调用行为有概率误差协议本身不能替代业务鉴权。我的做法是在每个 MCP Server 前面加一层薄薄的“权限过滤”Server 负责能力暴露但不直接持有生产系统的完整凭据真正执行敏感操作时由内部系统再验一次权限并记录审计日志。这样即使客户端的工具列表被误用风险也能被控制在最小范围。另外远程 Server 的 URL 一旦暴露出去等于把工具接口公开在了网络上至少要做访问令牌校验最好再配上 IP 白名单这类网络层限制。5.4 生态观察MCP 正在把工具接入变成“即插即用”这几个月观察下来MCP 生态最明显的变化是垂直领域的 Server 越来越多。有人给浏览器自动化工具做了 MCP 封装让模型可以直接控制页面有人给设计工具接入了 MCP模型可以生成设计稿参数安全测试领域也有对应的 Server把专业工具的能力开放给模型甚至工业软件、硬件设计工具链里都开始出现 MCP 集成。这些集的共同特点是工具本身没有变变的是它们都开始用同一种语言和模型对话。对普通开发者来说这意味着以后做智能体可能不再需要从零实现每个工具的接入而是去配置对应的 MCP Server。就像安装软件时不用关心驱动程序怎么写一样。这背后的影响是深远的工具能力的复用门槛被大幅拉低智能体的组合空间成倍扩大。我个人在实际操作中的体会是MCP 并不是一个必须立刻替换掉 Function Calling 的新框架更多时候它是把工具接入这件事从“硬编码”变成“标准协议”。最大的收益不是少写了代码而是不同工具可以按照同一个语义互相组合团队讨论接入方案时终于有了共同语言。如果你的项目里工具数量已经超过十个、需要多人维护花一个下午把 MCP 跑通你大概率会重新理解“模型上下文”这几个字的分量。 
长河君 · 2026/11/3 8:25:08 · 阅读 1.2k MCP vs Function Calling：大模型工具接入的标准化演进
最近在技术群里聊大模型应用几乎每次都会绕到同一个话题MCP 到底解决了什么很多人的疑问是——模型厂商已经提供了 Function Calling函数也能传参、能返回结果为什么还要搞一个 MCP 标准协议说实话我一开始也有同样的困惑。直到在一个实际项目里把同一个工具分别用 Function Calling 和 MCP 各接了一遍才真正清楚差距在哪。这篇博文就围绕这个问题把 MCP 的设计哲学拆开聊适合后端工程师、AI 应用开发者以及那些正在纠结“要不要上 MCP”的团队参考。1. Function Calling 的真实面孔它解决了什么又卡在哪里1.1 先捋清楚 Function Calling 到底在做什么Function Calling函数调用本质上是模型 API 提供的一种能力开发者在请求里定义一组函数签名模型在生成回答时如果判断需要外部信息或执行某个动作会输出一个结构化的调用请求包括函数名和参数而不是直接生成自然语言。应用侧收到这个请求后在业务系统里真正执行函数把结果以消息形式回传给模型模型再基于执行结果生成最终回复。打个比方Function Calling 就像你给一个实习生配了一台对讲机对讲机上贴了十个按钮每个按钮对应一个动作。实习生跟你说“我按了 3 号按钮”但你得提前把按钮一个个装好而且每换一个工作场景、每换一台对讲机都要重新装一遍。这套机制在小规模场景下很好用它是大模型从“只会说话”走向“能够动手”的关键一步。今天几乎所有主流模型厂商都支持类似的工具调用能力这一点不需要怀疑。真正的问题是Function Calling 只定义了一个“模型怎么把函数调用请求说出来”的契约至于函数在哪里、怎么被发现、怎么被组织、多个系统之间怎么协作它完全不管。随着业务复杂度的上升这三块缺失会越来越刺眼。1.2 三个最容易感知的痛点无状态、无发现、无边界第一个痛点是“无状态”。每次调用都是独立的请求-响应对函数执行结果不会自动沉淀到后续流程。你要自己维护上下文把上一次的工具结果拼进下一次的消息序列。多轮对话一长上下文就变得臃肿模型也容易在拼接过程中丢掉关键信息。我在实际项目中见过不少团队用消息数组硬扛最后不得不做各种截断和压缩。第二个痛点是“无发现”。调用方必须在每次请求里把全部函数定义列出来模型和调用方之间没有任何动态协商的机制。只有三五个固定函数时没问题但当你维护一个包含几十上百个工具的业务系统时每次请求都要把全部定义重新传输一遍Token 消耗会变成一个真实的成本项。举个例子一个稍微复杂点的工具定义动辄几百 Token40 个工具就是几万 Token这还没算多轮对话的重复发送。第三个痛点是“无边界”。函数的实现放在哪个服务、由谁部署、如何认证、如何做权限控制Function Calling 一概不过问。它只完成“模型要调用、应用来执行”这一动作。不同团队各自定义各自的函数格式Python 团队一套、Node.js 团队一套时间一长就形成一个个“方言孤岛”彼此之间完全无法复用。1.3 让问题浮出水面的典型场景我在一个内部运维辅助项目里接手过一套告警查询功能最初就是 Function Calling 方式。客户端的函数列表只有五个查询接口运行得挺稳。后来业务方要求接入自助巡检、日志检索、工单创建甚至物料库存查询函数列表膨胀到四十多个。问题立刻爆发一次请求要塞好几 KB 甚至十几 KB 的函数定义延迟和成本同步上升新增一个工具要重新发布客户端业务方急得直拍桌子各团队用不同语言写的函数外壳参数风格不统一模型经常在参数格式上出错。后来我们实在撑不住了把函数从客户端里抽出来做成一个独立的工具服务由客户端动态发现。这一步虽然是无意中做的但回头看其实就是被现实逼着走向了 MCP 的思路。这件事让我彻底想明白Function Calling 擅长解决的问题是“让模型能调用函数”但它没有回答“一套复杂工具生态应该如何被组织、暴露和复用”的问题。后者才是 MCP 真正要解的题。2. MCP 的背后与其说协议不如说一套会话模型2.1 从“函数”到“客户端-服务器”MCP 的整体轮廓MCPModel Context Protocol是模型与外部工具、数据源进行标准化交互的一种开放协议。注意它不是某一个厂商的 SDK也不是一个框架而是一套基于 JSON-RPC 2.0 的通信约定核心思想是把“函数”提升为“服务”。理解了这个转变就理解了一半的 MCP。我常用一个类比MCP 之于 AI 工具生态就像 USB-C 之于外设。USB-C 只规定物理接口和通信规范至于你接的是硬盘、显示器还是充电器由设备自己的驱动和固件实现。MCP 规定的也是“模型侧和工具侧之间的接口规范”工具内部的具体逻辑完全由服务方自己实现。MCP 的标准角色有三个Server 是提供能力的一方可以暴露工具、资源和提示词Client 是在 Host 内部与 Server 建立连接的连接器Host 是承载整个交互流程的宿主比如桌面客户端、IDE、各种智能体框架。这里有个容易混淆的点Host 和 Client 到底什么关系一句话Host 是用户面对的产品Client 是 Host 内部专门负责某一条工具连接的组件。这个分层让一套 Host 可以同时连接多个不同来源的 Server每个 Server 各自维护生命周期和数据互不干扰。2.2 JSON-RPC 之上的三大原语工具、资源、提示词MCP 把能力抽象成三类这是它跟 Function Calling 拉开差距的关键。第一类是工具Tools表示可控的动作比如执行 SQL、创建工单、调用外部 API语义上和 Function Calling 接近但工具是在 Server 上动态发现而不是写死在客户端请求里。第二类是资源Resources表示可读的数据比如文件内容、数据库查询结果、监控指标。客户端通过 URI 读取资源资源更新时可以推通知。第三类是提示词Prompts表示可复用的提示模板用于引导模型按既定模式完成任务比如“生成周报”或“按模板审核变更”。为什么这三类缺一不可因为一个完整的智能体不应该只会调用动作它还需要能够“查看”数据获取上下文以及“套用模式”来规范输出。Function Calling 只覆盖了“动作”这一类所以很多复杂任务做起来很别扭。举个例子你要让模型分析一份服务器日志Function Calling 只能让它把日志内容作为字符串参数传进函数日志一大就超出上下文限制而 MCP 的资源可以直接给模型一个可读取的 URI按需拉取避免了无意义的搬运。工具和资源之间的边界也不是死的。同一个后端能力既可以通过资源暴露为只读数据也可以通过工具暴露为可写动作。设计时要想清楚这个能力的核心语义是什么——是数据还是操作。我见过一些团队把查询接口做成工具导致模型频繁用工具去拉一整张大表既浪费时间又烧 Token正确做法应该是把这种高频只读查询设计成资源。2.3 一次性握手与能力协商为什么 MCP 更省对比 Function Calling 每次请求都带全量函数定义的做法MCP 把发现和调用拆成了两个阶段从结构上就解决了“工具定义膨胀”的问题。第一阶段是初始化握手。Client 向 Server 发送initialize请求带上协议版本和客户端能力说明Server 返回协议版本、服务端能力和服务信息随后 Client 发送notifications/initialized通知双方进入就绪状态。这一阶段回答的是“这个 Server 是什么、支持哪些协议能力”的问题。第二阶段是动态发现。Client 可以随时调用tools/list、resources/list、prompts/list等接口获取能力清单。清单不会塞进每一次模型请求里而是缓存在 Client 侧按需更新。关键点在这里在具体实现中MCP Client 会把发现到的工具转换成目标模型可以理解的 Function Calling 格式再走模型原生调用链路。也就是说MCP 和 Function Calling 并不是非此即彼的替代关系在很多架构里MCP Client 就是用来生成高质量工具配置的前置层。想明白这一点你就不会再纠结“到底选哪个”而是会考虑“在什么层级用哪一个”。2.4 设计哲学标准化“接口”而非“实现”前面说的是 MCP 是什么、怎么工作真正值得琢磨的是它背后的选择逻辑。第一MCP 选择定义“交互协议”而不是“API 规范”。它不规定工具用什么语言实现、数据存哪里任何实现了 JSON-RPC 消息交换的服务都可以成为 Server。约定的是双方的通信方式而不是业务实现方式这样既保住了生态的多样性又保证了互操作性。第二MCP 把“上下文”作为一等公民。协议名字里特意带上 Context意味着它着眼的不只是函数调用而是模型获取上下文的全过程。模型通过资源了解世界通过工具改变世界通过提示词规范对话方式三者合起来才是完整的上下文。设计者很清楚真正制约智能体的不是“能不能调用”而是“有没有足够的、结构化的上下文”。第三面向生态而非面向单点。单一 Function Calling 是模型 API 里的一个参数槽位跟着某个厂商的版本走MCP 是一个开放标准任何团队都能实现自己的 Server。现在能搜到的 Server 五花八门有做浏览器自动化的有接设计工具的有接安全测试工具的也有接音视频处理和 PLC 工程的。这说明 MCP 的目标是让所有人都往同一个接口上接入而不是围绕某一家的实现转。3. 协议拆解从头到尾走一遍 MCP 的交互流程3.1 完整的一次生命周期一个 MCP 连接的生命周期大致是创建 - 初始化 - 就绪 - 运行 - 关闭。整个生命周期里初始化是最容易出问题的环节。流程是这样的Client 建立传输通道可能是 stdio 也可以是 Streamable HTTP然后 Client 发送initialize请求附上协议版本和客户端能力Server 返回InitializeResult包含服务端信息、支持的协议版本和能力声明Client 再发送notifications/initialized通知确认初始化结束。完成这套握手之后双方才开始正常的工具调用和资源读取。这里有个最常见的误操作没有等待notifications/initialized就发送tools/list或tools/call。部分实现比较宽容会自动处理但严格按协议讲未完成初始化的连接发出的请求Server 是可以拒绝的。我在自定义 Server 里对非法时序直接返回错误并打日志结果帮客户端暴露了不少时序 bug。另一个容易忽视的点是协议版本协商Client 和 Server 可能支持不同版本initialize阶段会把双方的能力交集找出来后续功能必须在这个交集内使用。3.2 工具的发现与调用消息层级细看拿工具发现来说Client 发送{ jsonrpc: 2.0, method: tools/list, id: 1, params: {} }Server 返回{ jsonrpc: 2.0, id: 1, result: { tools: [ { name: query_alert, description: 查询告警信息可按级别和关键字过滤, inputSchema: { type: object, properties: { level: {type: string, enum: [info, warning, critical]}, keyword: {type: string} }, required: [] } } ] } }注意这里的inputSchema用的是 JSON Schema不是某个厂商私有的参数格式。这是 MCP 能被多种客户端复用的原因之一一切的边界都落到标准 JSON Schema 上客户端适配层只需要把这份 Schema 转换成目标模型的 Function Calling 参数即可。工具描述字段description也至关重要模型的工具选择很大程度上依赖这段自然语言描述。再看tools/call{ jsonrpc: 2.0, method: tools/call, id: 2, params: { name: query_alert, arguments: { level: critical, keyword: CPU } } }Server 返回结果有两种形态一种是完成结果包含多个content块每个块有type常见的是text也支持image等类型另一种是进度更新适合长耗时任务向客户端持续回报进度。返回结构里还允许带isError标志区分业务错误和协议错误。我特别欣赏这种设计业务上的“没查到数据”和协议上的“参数格式错误”是两回事模型可以分别处理。3.3 传输层stdio 与 Streamable HTTP 的选择逻辑MCP 的传输层经历过演进早期支持 stdio 和 HTTPSSE后来社区合并出了 Streamable HTTP 方案把普通 HTTP 请求和 SSE 响应收到一个通道里。今天官方推荐的就是两个stdio 和 Streamable HTTP。stdio 适合本地场景。Server 作为子进程被客户端拉起通过标准输入输出通信没有端口、网络配置、认证这些额外工作。对本地工具来说权限模型天然贴近当前操作系统用户简单直接。缺点很明显不能跨机器、不能服务多客户端。Streamable HTTP 则适合远程部署Server 作为 HTTP 服务客户端通过 URL 访问。选择时先问自己一个问题工具是跑在用户本地的还是集中部署在服务端的本地优先 stdio远程必须走 HTTP。远程模式下要特别注意几点URL 暴露在客户端的配置文件里意味着必须有访问控制Server 要处理并发请求长连接需要心跳或者空闲超时策略。我在一些项目里见过混合做法本地智能体通过 stdio 连接本地 MCP ServerServer 内部再去访问远程 API敏感凭据留在服务端不落到用户终端。这个模式的优点是既享受了 stdio 的简单性又把安全边界控制在了服务端。4. 实操半小时搭一个可用的 MCP Server 并接入客户端4.1 最小实现一个“开发辅助”的 MCP Server我用 FastMCP 的 Python SDK 写过最小实现包含两个工具和一条资源。安装命令就一条pip install mcp[cli]核心代码如下from mcp.server.fastmcp import FastMCP mcp FastMCP(dev-helper) mcp.tool() def calc_work_hours(start: str, end: str) - str: 根据开始时间和结束时间计算工作时长小时。时间格式为 HH:MM。 from datetime import datetime fmt %H:%M t1 datetime.strptime(start, fmt) t2 datetime.strptime(end, fmt) if t2 t1: t2 t2.replace(dayt2.day 1) return f{round((t2 - t1).total_seconds() / 3600, 2)} 小时 mcp.tool() def best_practice(topic: str) - str: 针对开发主题返回一条最佳实践建议。 rules { api: 接口稳定优先先冻结契约再并行开发。, auth: 认证尽量走标准流程不要自研校验逻辑。, } return rules.get(topic, f关于 {topic} 的建议先写测试再写实现。) mcp.resource(dev://now) def now_time() - str: 当前服务器时间用于上下文校准。 from datetime import datetime return datetime.now().isoformat() if __name__ __main__: mcp.run(transportstdio)这段代码已经能演示 MCP 的核心能力两个工具对应“动作”一条资源对应“可读数据”。FastMCP 会把mcp.tool()下面装饰器的 docstring 自动提取为工具描述所以写描述就是写 docstring别偷懒。我见过很多工具调用失败的案例最后排查下来都是描述含糊、模型猜不到这个工具应该在什么时候用。描述里如果可能尽量带上使用场景、参数格式、返回值示例。4.2 让客户端真正连上这个 Server本地调试时最简单的办法是用 stdio 方式直接拉起这个 Python 脚本。在支持 MCP 的客户端里添加一条 stdio 配置命令指向带 Python 环境的执行器python /path/to/dev_helper.py部分新版本客户端提供命令行管理 MCP 连接比如claude mcp add dev-helper -- python /path/to/dev_helper.py如果 Server 走远程就换成一条 HTTP 地址claude mcp add dev-helper --transport http http://your-host:8000/mcp用 Python 实现远程版本也很快把 FastMCP 的启动方式改成transporthttp即可SDK 内置了 Streamable HTTP 实现。具体路径以你的 Server 实现为准有的框架默认挂在/mcp有的挂在其他根路径。远程模式必须处理认证和端口暴露不要在裸 HTTP 上暴露管理类工具这是最基本的底线。4.3 调试工具的辅助Inspector 与日志MCP 社区提供了官方 Inspector可以像图形界面一样浏览 Server 暴露出的工具、资源并手动发起调用npx modelcontextprotocol/inspector它会让你选择以 stdio 还是 HTTP 方式连接到目标 Server然后在一个网页界面里查看工具列表、填写参数、发起调用、观察返回值。我习惯在 Server 里开启 debug 级别的日志把传输层消息打印出来看。很多时候排查问题不需要猜模型在想什么直接看协议层消息就够了是哪一步卡住、返回了什么错误、参数序列化后是什么样子一目了然。5. 常见问题与避坑实录5.1 超时与重试最常见的三个错误第一类问题客户端超时。默认超时往往在几十秒量级如果你的 Server 是启动很慢的 Python 进程或者某个工具内部做了长时间的外部网络调用很容易触发超时。解决思路不是盲目调大超时时间而是区分工具类型快速读操作应该保证百毫秒级响应长耗时任务设计成“提交任务 查询状态”的模式而不是让模型同步等待。一个小技巧是确保 Server 对空闲探测ping及时响应不要因为某个主线程被阻塞而导致整个进程对 ping 无应答。第二类问题传输方式不匹配。用 stdio 配置去连远程 HTTP 地址或者反过来在远程部署时监听 stdin都会导致连接建立失败或握手超时。排查时先确认配置里的 transport 参数和实际 Server 类型一致。第三类问题参数 Schema 写得太含糊。模型填充参数出错时不要只怪模型。把inputSchema里的字段约束写清楚加上description、enum、format甚至示例值。我给calc_work_hours的字段加了示例格式后调用成功率肉眼可见地提升。工具描述和字段描述是模型正确调用的前提这部分投入的每一分钟都是值得的。5.2 何时用 Function Calling何时上 MCP一个实用的判断标准如果智能体只需要调用三五个内部函数团队不大发布节奏快直接用 Function Calling 就够了引入 MCP 是额外的一层成本。如果工具数量会持续增长、需要多个客户端复用、或者工具要独立开发和独立发布那 MCP 的收益就体现出来了。服务方维护一份实现多个客户端共享不再为每个客户端单独适配。如果产品形态是“给用户提供一个可扩展的工具市场”MCP 几乎就是必选项。每个第三方工具打包成一个 Server用户安装即用客户端无需为每个工具发版。这个选择不是技术洁癖的问题而是成本与杠杆的取舍。5.3 安全与作用域别把整套后端直接暴露给模型MCP 让工具接入变得容易也带来了新的安全边界。最重要的注意事项不要在 Server 里暴露超出模型任务所需范围的权限。一个只用于查询告警的 Server就不要顺手把删除接口也暴露成工具。模型的调用行为有概率误差协议本身不能替代业务鉴权。我的做法是在每个 MCP Server 前面加一层薄薄的“权限过滤”Server 负责能力暴露但不直接持有生产系统的完整凭据真正执行敏感操作时由内部系统再验一次权限并记录审计日志。这样即使客户端的工具列表被误用风险也能被控制在最小范围。另外远程 Server 的 URL 一旦暴露出去等于把工具接口公开在了网络上至少要做访问令牌校验最好再配上 IP 白名单这类网络层限制。5.4 生态观察MCP 正在把工具接入变成“即插即用”这几个月观察下来MCP 生态最明显的变化是垂直领域的 Server 越来越多。有人给浏览器自动化工具做了 MCP 封装让模型可以直接控制页面有人给设计工具接入了 MCP模型可以生成设计稿参数安全测试领域也有对应的 Server把专业工具的能力开放给模型甚至工业软件、硬件设计工具链里都开始出现 MCP 集成。这些集的共同特点是工具本身没有变变的是它们都开始用同一种语言和模型对话。对普通开发者来说这意味着以后做智能体可能不再需要从零实现每个工具的接入而是去配置对应的 MCP Server。就像安装软件时不用关心驱动程序怎么写一样。这背后的影响是深远的工具能力的复用门槛被大幅拉低智能体的组合空间成倍扩大。我个人在实际操作中的体会是MCP 并不是一个必须立刻替换掉 Function Calling 的新框架更多时候它是把工具接入这件事从“硬编码”变成“标准协议”。最大的收益不是少写了代码而是不同工具可以按照同一个语义互相组合团队讨论接入方案时终于有了共同语言。如果你的项目里工具数量已经超过十个、需要多人维护花一个下午把 MCP 跑通你大概率会重新理解“模型上下文”这几个字的分量。