做 AI 应用时MCP 和 Function Calling 经常一起出现也经常被说成同一件事。常见说法有两种“MCP 就是更高级的 Function Calling。”“有了 MCP就不需要 Function Calling 了。”这两种说法都混淆了它们所在的层次。先给结论Function Calling 解决的是模型如何向应用表达“我想调用哪个工具参数是什么”。MCP 解决的是应用如何用统一协议发现、连接和调用外部能力。一个位于“模型和应用”之间一个位于“应用和能力提供方”之间。它们可以单独使用也可以组合使用但不是替代关系。一、先把调用链画对一个同时使用 Function Calling 和 MCP 的典型流程是用户 │ ▼ LLM │ Function Calling │ 模型返回调用 queryStudentStats(studentName张三) ▼ AI 应用 / MCP Host │ MCP Client │ 发送 tools/call ▼ MCP Server │ ▼ 数据库、文件系统、业务 API 或其他服务这张图里有两个完全不同的边界LLM → AI 应用模型通过 Function Calling 表达工具调用意图。AI 应用 → MCP Server应用通过 MCP 发现并调用外部能力。如果不用 MCPAI 应用也可以把 Function Calling 映射成本地 Java 方法、REST API 或数据库查询。如果不用 Function Calling应用也可以根据用户点击、固定工作流或业务规则主动调用 MCP Tool或者直接读取 MCP Resource。所以更准确的说法是Function Calling 和 MCP 经常协作但彼此都不是对方的前置条件。二、Function Calling 到底是什么Function Calling也常被称为 Tool Calling是模型 API 提供的一种工具调用接口。应用先把工具名称、说明和参数结构告诉模型。以常见的函数工具定义为例{type:function,function:{name:searchKnowledge,description:从教学知识库中检索相关资料,parameters:{type:object,properties:{query:{type:string,description:需要检索的问题}},required:[query],additionalProperties:false},strict:true}}当用户问“帮我查一下三角函数的资料”时模型可能不直接生成答案而是返回一个结构化调用请求{name:searchKnowledge,arguments:{query:三角函数}}这里最容易误解的一点是模型通常只生成调用请求并没有执行你的 Java 方法。对于自定义函数后续步骤仍由应用负责把可用工具和用户问题发给模型接收模型返回的工具调用请求校验参数并执行本地代码或者把请求转发给外部系统把工具结果交还给模型模型基于工具结果生成最终回答或者继续请求其他工具。因此Function Calling 更像是模型和应用之间的一种“结构化协作接口”。它回答的是模型是否需要工具模型选择哪个工具模型准备传什么参数应用如何把工具结果接回模型对话。至于工具位于当前 JVM、另一个微服务还是第三方平台不是 Function Calling 本身关心的问题。三、MCP 到底是什么MCP 全称是 Model Context Protocol是一套建立在 JSON-RPC 2.0 之上的开放协议。它采用 Host、Client、Server 架构MCP Host承载 AI 体验的应用负责权限、上下文和模型集成MCP ClientHost 中负责连接某个 MCP Server 的协议组件MCP Server按统一格式向 Client 暴露能力。MCP Server 暴露的不只有 Tool还包括三类重要能力Tools可执行操作例如查数据库、调用 API、写文件Resources可读取的上下文例如文件内容、Git 历史、数据库记录Prompts可复用的提示模板或交互模板。MCP 还定义了版本兼容、能力声明、错误结构、授权框架、通知等协议行为。以 Tool 为例客户端可以通过tools/list获取当前可用工具{jsonrpc:2.0,id:1,method:tools/list,params:{}}再通过tools/call发起调用{jsonrpc:2.0,id:2,method:tools/call,params:{name:searchKnowledge,arguments:{query:三角函数}}}为了突出核心字段上面的示例省略了当前规范要求的_meta协议元数据。MCP 当前定义了两种标准传输stdioHost 启动本地子进程通过标准输入输出交换消息Streamable HTTP通过统一 HTTP 端点传输消息并可使用请求级 SSE 流返回结果或通知。这也说明了另一个常见误区MCP Server 不一定是远程微服务。它也可以是本机上的 stdio 进程。MCP 的核心价值不是“把一次 Java 方法调用改成 HTTP”而是让不同 Host 和不同能力提供方共享一套可发现、可组合、可替换的接入协议。四、它们是怎样组合起来的假设一个教学 Agent 需要查询学生成绩完整链路可以拆成六步。第一步MCP Client 发现工具AI 应用连接 MCP Server通过tools/list得到{name:queryStudentStats,description:查询指定学生的作业统计,inputSchema:{type:object,properties:{studentName:{type:string,description:学生姓名}},required:[studentName]}}第二步Host 把工具交给模型Host 将 MCP Tool 的名称、描述和输入 Schema 转换为模型 API 能理解的工具定义。如果模型平台原生支持远程 MCP这层转换和协议交互也可能由平台代为完成但概念上的两层边界仍然存在。第三步模型做出选择用户问“张三最近成绩怎么样”模型通过 Function Calling 返回{name:queryStudentStats,arguments:{studentName:张三}}此时模型只表达了调用意图。第四步Host 调用 MCP ToolHost 中的 MCP Client 把这个意图转换成tools/call请求发送给 MCP Server。第五步MCP Server 执行业务逻辑Server 校验权限和参数调用数据库或业务服务然后按 MCP Tool Result 格式返回结果。第六步模型组织答案Host 把工具结果交还给模型模型生成最终回复张三本学期共提交 8 次作业平均分 82.5 分。 最近一次作业得分 78 分相比前三次平均成绩略有下降。这条链路里的分工非常清楚Function Calling负责模型侧的工具选择和参数生成MCP负责应用侧的能力发现、协议调用和结果交换业务代码负责真正查询数据库、操作文件或调用外部 API。不要把“决定调用”“传输调用”和“执行调用”混成一层。五、核心区别对照维度Function CallingMCP所在边界模型 ↔ 应用MCP Client ↔ MCP Server核心问题模型如何表达工具调用请求能力如何被统一发现、连接和调用工具定义来源应用提交给模型 APIServer 通过tools/list暴露参数结构通常使用 JSON SchemaTool 的inputSchema使用 JSON Schema谁选择工具通常由模型也可由应用限制MCP 协议本身不负责模型决策谁执行工具应用或平台执行/转发MCP Server 接收tools/call后执行业务逻辑传输方式取决于具体模型提供商 APIstdio、Streamable HTTP 或自定义传输除工具外的能力取决于模型平台Resources、Prompts以及其他协议能力跨实现复用不同模型平台格式可能不同目标就是让 Host 与 Server 按统一协议互操作能否独立使用可以不需要 MCP可以不要求每次都由模型自动选工具最重要的一行是第一行它们工作的边界不同。六、四个最常见的误区误区一MCP 是 Function Calling 的升级版不是。升级关系意味着新方案覆盖旧方案的职责但 MCP 并不替模型决定调用哪个工具。它解决的是另一层的标准化接入问题。误区二有了 MCP 就不需要 Function Calling也不是。如果希望模型根据自然语言自主选择 MCP Tool模型侧仍然需要某种 Tool Calling 能力。只不过有些模型平台已经原生支持 MCP把中间适配过程封装起来了。误区三用了 Function Calling HTTP 就等于 MCP不等于。Function Calling 之后当然可以手写 HTTP 请求但这只是你自己的适配方式。MCP 还规定了工具发现、Schema、结果结构、版本兼容、传输和授权等共同约定。“能远程调用”不等于“实现了 MCP”。误区四用了 MCP 就不用写工具描述仍然要写而且必须认真写。Tool 的name、description和inputSchema会直接影响模型能否选对工具、填对参数。MCP 省掉的是各个 Host 与 Server 重复定义接入协议的成本不是工具语义设计的成本。七、什么时候只用 Function Calling什么时候引入 MCP只用 Function Calling 通常就够了工具只服务于一个应用工具和编排代码位于同一个项目工具数量少且变化不频繁不需要接入其他 MCP Host 或复用外部 MCP Server直接调用本地方法或既有 REST API 已经足够清晰。例如在一个 Spring Boot 单体应用里LangChain4j 直接持有几个 Tool 对象通常没有必要为了“看起来更 Agent”而额外引入 MCP。引入 MCP 更有价值同一套能力要被多个 AI 应用复用Host 与工具由不同项目或团队维护希望接入现有 MCP Server 生态既要提供 Tools也要提供 Resources 或 Prompts需要统一能力发现、版本兼容和远程接入方式希望模型或框架可替换而能力服务保持稳定。判断标准不是“工具超过几个”或者“团队超过几个人”而是你是否真的需要一个稳定、可复用、跨实现的能力边界。八、MCP 也不是免费午餐MCP 解决了标准化问题但不会自动解决所有工程问题。引入 MCP 后你仍然要面对Tool Schema 的兼容和演进参数与返回结果的校验工具权限和用户授权敏感操作的人工确认超时、重试、幂等和错误恢复多个 Server 之间的工具重名日志、审计和链路追踪不可信 Tool 描述或结果带来的提示注入风险。如果使用远程 Streamable HTTP还会增加网络和远程服务运维成本如果使用本地 stdio则不一定存在网络往返和独立部署成本。尤其需要注意MCP 提供授权和协议框架不代表接入一个 MCP Server 后天然安全。Server 仍要校验输入、实施访问控制、限流并清理输出Client 仍要在敏感操作前向用户确认并把远程 Server 返回的元数据和内容当作不可信输入处理。九、2026 年的规范变化旧教程为什么看起来不一样截至 2026 年 8 月当前 MCP 规范版本是2026-07-28。这一版把核心协议改为无状态模型请求携带自己的协议版本和 Client Capabilities不再依赖旧版的initialize/initialized握手和Mcp-Session-Id。标准传输仍然是stdioStreamable HTTP。因此如果你在旧教程里看到以下内容2024-11-05协议版本独立的 HTTP SSE 传输必须先执行initialize后续请求必须携带Mcp-Session-Id它们描述的是旧版 MCP并不一定是代码写错了。阅读 MCP 文章时一定先确认文章基于哪个协议版本。这也是为什么“手写 MCP Server”不能只模仿几段旧 JSON协议版本、传输和兼容策略都属于实现的一部分。十、最后用三句话记住Function Calling 是模型侧的工具调用接口模型表达调用意图应用处理调用闭环。MCP 是应用侧的能力接入协议统一发现、连接和调用 Tools、Resources、Prompts。两者可以组合但谁也不是谁的升级版。如果一定要做一个简化类比Function Calling 像一张由模型填写的“调用单”MCP 像能力提供方和调用方共同遵守的“接入规范”。模型填好调用单之后应用可以在本地执行也可以走 REST更可以把它映射为 MCP 的tools/call。这才是两者真正的关系。参考资料OpenAIFunction Calling 官方指南OpenAIMCP 与 ConnectorsMCP 2026-07-28 规范总览MCP ArchitectureMCP Tools 规范MCP Transports 规范本文会随 MCP 规范继续修订。原文与后续更新收录在我的技术博客https://www.lkl-zero.top/2026/06/14/2026-06-14-mcp-vs-function-calling/