Function Calling 与 MCP 深度对比从原理到实践一文讲透区别与关系一、问题场景“我用 Claude API 的 Tool Use 功能已经很顺手了为什么还要学 MCP”“Function Calling 和 MCP 到底是什么关系它们是竞争还是互补”“团队要统一 AI 工具调用方案应该选 Function Calling 还是 MCP”这三个问题是近半年来我被问得最多的问题。很多开发者在接触 MCPModel Context Protocol之后第一反应是困惑——Anthropic 不是已经有 Tool Use 了吗OpenAI 不是已经有 Function Calling 了吗为什么又冒出来一个 MCP本文将从三个维度彻底讲清楚这个问题概念层Function Calling 和 MCP 各自是什么解决什么问题关系层它们在不同层面的分工——就像 HTTP 和 Web 应用的关系实战层同一个工具分别用 Function Calling 和 MCP 实现直观对比差异读完这篇文章你不仅能清晰理解两者的关系还能知道在实际项目中如何选型和组合使用。二、原理分析2.1 Function Calling 是什么Function Calling 是大模型的原生能力让模型能够识别用户意图并决定我应该调用哪个函数。当用户问北京今天天气怎么样模型本身不知道实时天气。但如果你定义了一个 get_weather 函数并告诉模型模型就能推断出需要调用这个函数并生成调用参数 {“city”: “北京”}。各家厂商的 Function Calling 实现厂商名称定义格式OpenAIFunction Calling / ToolsJSON SchemaAnthropicTool UseJSON Schemainput_schemaGoogleFunction DeclarationOpenAPI / JSON Schema核心流程以 Claude Tool Use 为例① 开发者定义 Tool 描述名称 描述 JSON Schema ② 将 Tool 定义随请求一起发送给模型 ③ 模型推理后返回 tool_use 块含函数名和参数 ④ 开发者在自己的代码中执行函数 ⑤ 将执行结果以 tool_result 块返回给模型 ⑥ 模型基于结果生成最终自然语言回复关键点Function Calling 只负责决定调用什么 生成调用参数不负责执行。函数执行完全由开发者的代码完成。2.2 MCP 是什么MCPModel Context Protocol是协议标准定义了 AI 应用与外部工具/数据源之间的通信方式。MCP 采用 Client-Server 架构MCP ClientAI 应用端Claude Desktop、Cursor、你的应用MCP Server工具提供端你开发的工具服务通信协议JSON-RPC 2.0通过 stdio 或 HTTPSSE 传输MCP 定义了三种 Server 能力原语Tools可执行的函数模型可以调用Resources可读取的数据作为模型推理的上下文Prompts预定义的提示词模板MCP 的核心价值一次编写到处使用。你写的 MCP Server 可以被 Claude Desktop、Cursor、Continue 等所有支持 MCP 的 Client 使用无需为每个平台适配。2.3 核心区别不同层面的东西Function Calling 和 MCP 不是竞争关系它们在不同的抽象层面工作┌──────────────────────────────────────────┐ │ 用户问题 │ │ 北京今天天气怎么样 │ ├──────────────────────────────────────────┤ │ AI 模型Claude / GPT │ │ ┌────────────────────────────────┐ │ │ │ Function Calling / Tool Use │ │ ← 模型能力层 │ │ 我需要调用 get_weather │ │ │ └────────────────────────────────┘ │ ├──────────────────────────────────────────┤ │ MCP 协议层 │ ← 协议标准层 │ Client → tools/call → Server │ ├──────────────────────────────────────────┤ │ MCP Server │ ← 工具实现层 │ def get_weather(city): ... │ └──────────────────────────────────────────┘类比理解类比对应关系Function Calling 汽车的方向盘模型通过它来操控外部工具MCP 汽车的方向盘接口标准确保任何车都能用同一套方向盘你的 Tool 实现 具体的转向系统接收方向盘指令并执行Function Calling 是模型的大脑决定做什么MCP 是神经系统怎么传递信号Tool 实现是手脚实际执行。2.4 一张表讲清所有区别维度Function CallingMCP本质模型能力通信协议层级应用层模型推理传输层Client-Server 通信标准化各家私有格式开放协议标准JSON-RPC 2.0谁实现AI 厂商OpenAI/Anthropic/Google任何人开源社区 你作用范围单次 API 调用内跨应用、跨平台、跨模型执行方式开发者代码自己执行函数MCP Client 自动调度执行可复用性绑定特定模型 API编写一次到处使用工具发现每次请求手动传入Client 自动发现tools/list生命周期单次请求-响应持久化进程/服务典型场景在代码中调用模型并处理 Tool构建可被多个 AI 应用共享的工具生态2.5 它们的关系互补而非替代MCP 离不开 Function CallingMCP 本身只是定义了如何发现和调用工具但决定调用哪个工具这个智能推理步骤仍然需要模型的 Function Calling 能力。MCP 解决的是管道问题Function Calling 解决的是判断问题。Function Calling 离不开 MCP的好处没有 MCP 时用 Function Calling 搭建工具体系是这样的写 Tool 定义JSON Schema写 Tool 执行逻辑每次 API 调用时手动传入 Tool 定义在回调中手动匹配 tool_use 并执行有 MCP 后变成写一次 MCP Server所有支持 MCP 的应用直接使用无需手动传入 Tool 定义Client 自动发现无需手动执行回调Client 自动调度一句话总结MCP 是 Function Calling 的工程化基础设施——它让 Function Calling 变得标准化、可复用、跨平台。三、实践验证用一个具体的天气查询工具分别用纯 Function Calling 和 MCP Server 两种方式实现直观对比差异。3.1 方式一纯 Function CallingClaude API 纯 Function Calling 方式 —— 所有逻辑写在一个文件里 每次调用都要手动传入 Tool 定义 手动执行回调 fromanthropicimportAnthropic clientAnthropic()# 1. 定义 Tooltools[{name:get_weather,description:获取指定城市的天气信息,input_schema:{type:object,properties:{city:{type:string,description:城市名称}},required:[city]}}]# 2. 定义执行函数和 Tool 定义分离defget_weather(city:str)-dict:# 模拟天气查询return{city:city,temp:25,condition:晴}# 3. 发起请求responseclient.messages.create(modelclaude-sonnet-4-6,max_tokens1024,toolstools,# 每次请求都要传messages[{role:user,content:北京天气怎么样}])# 4. 手动处理 tool_use 回调ifresponse.stop_reasontool_use:forblockinresponse.content:ifblock.typetool_use:ifblock.nameget_weather:cityblock.input[city]resultget_weather(city)# 5. 手动发送 tool_resultresponseclient.messages.create(modelclaude-sonnet-4-6,max_tokens1024,toolstools,# 又要传一遍messages[{role:user,content:北京天气怎么样},{role:assistant,content:[block]},{role:user,content:[{type:tool_result,tool_use_id:block.id,content:str(result)}]}])print(response.content[0].text)痛点Tool 定义和执行逻辑分离维护时容易不同步每次 API 调用都要传 tools 参数浪费 Tokentool_use 回调需要手动匹配和处理换个应用如 Cursor就得重写一遍3.2 方式二MCP Server工具定义 执行一体化server.py MCP Server 方式 —— 工具定义和执行逻辑内聚在一起 一次编写Claude Desktop、Cursor、Continue 等都能直接用 importjsonfrommcp.serverimportServerfrommcp.server.stdioimportstdio_server serverServer(weather-server)# Tool 定义和执行逻辑在一起内聚且同步server.list_tools()asyncdefhandle_list_tools():return[{name:get_weather,description:获取指定城市的天气信息包括温度和天气状况,inputSchema:{type:object,properties:{city:{type:string,description:城市名称}},required:[city]}}]server.call_tool()asyncdefhandle_call_tool(name:str,arguments:dict):ifnameget_weather:cityarguments[city]result{city:city,temp:25,condition:晴}return[{type:text,text:json.dumps(result,ensure_asciiFalse)}]asyncdefmain():asyncwithstdio_server()as(read_stream,write_stream):awaitserver.run(read_stream,write_stream,server.create_initialization_options())if__name____main__:importasyncio asyncio.run(main())Claude Desktop 配置{mcpServers:{weather-server:{command:python,args:[C:/path/to/server.py]}}}优势Tool 定义和实现在一起修改时不会遗漏Client 通过 tools/list 自动发现Token 零开销tool_use 回调由 MCP Client 自动调度一次编写跨应用复用3.3 对比总结方面纯 Function CallingMCP Server代码量~50 行含回调处理~30 行Tool 定义与实现分离易不同步内聚同步更新跨应用复用每次重写一次编写到处使用Token 开销每次请求传 tools零自动发现回调处理手动匹配自动调度部署代码内嵌独立进程/服务面试加分点Function Calling 是模型能力MCP 是协议标准两者在不同抽象层MCP 的 stdio Transport 天然隔离无需处理端口冲突tools/list 实现工具发现避免了每次请求手动传入MCP 生态已有 1000 开源 Server可以不用重复造轮子MCP 支持 Tool/Resource/Prompt 三种原语比纯 Function Calling 覆盖更多场景四、选型指南4.1 什么时候用纯 Function Calling只有 1-2 个简单工具不值得起一个 MCP Server一次性的原型验证工具逻辑和业务代码强耦合不需要跨应用复用4.2 什么时候用 MCP工具有多个使用场景/应用工具逻辑复杂值得独立维护团队协作工具可共享给同事需要工具发现和动态注册能力构建企业内部工具体系4.3 最佳实践两者结合在生产环境中推荐架构是┌─────────────────────┐ │ 你的 AI 应用 │ │ (Claude API 调用) │ ← Function Calling 做推理 ├─────────────────────┤ │ MCP Client SDK │ ← MCP 做通信 ├─────────────────────┤ │ 企业 MCP Server │ │ ┌─────┐ ┌─────┐ │ │ │用户API│ │订单API│ │ ← 业务工具实现 │ └─────┘ └─────┘ │ └─────────────────────┘模型用 Function Calling 决定该查什么MCP 负责把请求路由到正确的 Server 并执行两者各司其职。五、总结Function Calling 和 MCP 的关系可以用一句话概括Function Calling 是模型的决策大脑MCP 是工具的通信高速公路。它们不是竞争关系而是不同层面的互补。Function Calling 回答该做什么MCP 回答怎么做到。推荐学习路径先用 Function Calling 跑通一个 API 调用理解模型如何决定调用工具把同一个工具改写为 MCP Server体验一次编写到处使用的便利探索 MCP 生态在 github.com/modelcontextprotocol/servers 学习优秀实践构建企业的 MCP 工具体系让所有 AI 应用共享同一套工具基础设施延伸阅读Anthropic Tool Use 文档MCP 官方规范MCP Python SDKOpenAI Function Calling 文档理解这两者的关系你就站在了 LLM 应用开发的最前沿。
Function Calling 与 MCP 深度对比：从原理到实践，一文讲透区别与关系
Function Calling 与 MCP 深度对比从原理到实践一文讲透区别与关系一、问题场景“我用 Claude API 的 Tool Use 功能已经很顺手了为什么还要学 MCP”“Function Calling 和 MCP 到底是什么关系它们是竞争还是互补”“团队要统一 AI 工具调用方案应该选 Function Calling 还是 MCP”这三个问题是近半年来我被问得最多的问题。很多开发者在接触 MCPModel Context Protocol之后第一反应是困惑——Anthropic 不是已经有 Tool Use 了吗OpenAI 不是已经有 Function Calling 了吗为什么又冒出来一个 MCP本文将从三个维度彻底讲清楚这个问题概念层Function Calling 和 MCP 各自是什么解决什么问题关系层它们在不同层面的分工——就像 HTTP 和 Web 应用的关系实战层同一个工具分别用 Function Calling 和 MCP 实现直观对比差异读完这篇文章你不仅能清晰理解两者的关系还能知道在实际项目中如何选型和组合使用。二、原理分析2.1 Function Calling 是什么Function Calling 是大模型的原生能力让模型能够识别用户意图并决定我应该调用哪个函数。当用户问北京今天天气怎么样模型本身不知道实时天气。但如果你定义了一个 get_weather 函数并告诉模型模型就能推断出需要调用这个函数并生成调用参数 {“city”: “北京”}。各家厂商的 Function Calling 实现厂商名称定义格式OpenAIFunction Calling / ToolsJSON SchemaAnthropicTool UseJSON Schemainput_schemaGoogleFunction DeclarationOpenAPI / JSON Schema核心流程以 Claude Tool Use 为例① 开发者定义 Tool 描述名称 描述 JSON Schema ② 将 Tool 定义随请求一起发送给模型 ③ 模型推理后返回 tool_use 块含函数名和参数 ④ 开发者在自己的代码中执行函数 ⑤ 将执行结果以 tool_result 块返回给模型 ⑥ 模型基于结果生成最终自然语言回复关键点Function Calling 只负责决定调用什么 生成调用参数不负责执行。函数执行完全由开发者的代码完成。2.2 MCP 是什么MCPModel Context Protocol是协议标准定义了 AI 应用与外部工具/数据源之间的通信方式。MCP 采用 Client-Server 架构MCP ClientAI 应用端Claude Desktop、Cursor、你的应用MCP Server工具提供端你开发的工具服务通信协议JSON-RPC 2.0通过 stdio 或 HTTPSSE 传输MCP 定义了三种 Server 能力原语Tools可执行的函数模型可以调用Resources可读取的数据作为模型推理的上下文Prompts预定义的提示词模板MCP 的核心价值一次编写到处使用。你写的 MCP Server 可以被 Claude Desktop、Cursor、Continue 等所有支持 MCP 的 Client 使用无需为每个平台适配。2.3 核心区别不同层面的东西Function Calling 和 MCP 不是竞争关系它们在不同的抽象层面工作┌──────────────────────────────────────────┐ │ 用户问题 │ │ 北京今天天气怎么样 │ ├──────────────────────────────────────────┤ │ AI 模型Claude / GPT │ │ ┌────────────────────────────────┐ │ │ │ Function Calling / Tool Use │ │ ← 模型能力层 │ │ 我需要调用 get_weather │ │ │ └────────────────────────────────┘ │ ├──────────────────────────────────────────┤ │ MCP 协议层 │ ← 协议标准层 │ Client → tools/call → Server │ ├──────────────────────────────────────────┤ │ MCP Server │ ← 工具实现层 │ def get_weather(city): ... │ └──────────────────────────────────────────┘类比理解类比对应关系Function Calling 汽车的方向盘模型通过它来操控外部工具MCP 汽车的方向盘接口标准确保任何车都能用同一套方向盘你的 Tool 实现 具体的转向系统接收方向盘指令并执行Function Calling 是模型的大脑决定做什么MCP 是神经系统怎么传递信号Tool 实现是手脚实际执行。2.4 一张表讲清所有区别维度Function CallingMCP本质模型能力通信协议层级应用层模型推理传输层Client-Server 通信标准化各家私有格式开放协议标准JSON-RPC 2.0谁实现AI 厂商OpenAI/Anthropic/Google任何人开源社区 你作用范围单次 API 调用内跨应用、跨平台、跨模型执行方式开发者代码自己执行函数MCP Client 自动调度执行可复用性绑定特定模型 API编写一次到处使用工具发现每次请求手动传入Client 自动发现tools/list生命周期单次请求-响应持久化进程/服务典型场景在代码中调用模型并处理 Tool构建可被多个 AI 应用共享的工具生态2.5 它们的关系互补而非替代MCP 离不开 Function CallingMCP 本身只是定义了如何发现和调用工具但决定调用哪个工具这个智能推理步骤仍然需要模型的 Function Calling 能力。MCP 解决的是管道问题Function Calling 解决的是判断问题。Function Calling 离不开 MCP的好处没有 MCP 时用 Function Calling 搭建工具体系是这样的写 Tool 定义JSON Schema写 Tool 执行逻辑每次 API 调用时手动传入 Tool 定义在回调中手动匹配 tool_use 并执行有 MCP 后变成写一次 MCP Server所有支持 MCP 的应用直接使用无需手动传入 Tool 定义Client 自动发现无需手动执行回调Client 自动调度一句话总结MCP 是 Function Calling 的工程化基础设施——它让 Function Calling 变得标准化、可复用、跨平台。三、实践验证用一个具体的天气查询工具分别用纯 Function Calling 和 MCP Server 两种方式实现直观对比差异。3.1 方式一纯 Function CallingClaude API 纯 Function Calling 方式 —— 所有逻辑写在一个文件里 每次调用都要手动传入 Tool 定义 手动执行回调 fromanthropicimportAnthropic clientAnthropic()# 1. 定义 Tooltools[{name:get_weather,description:获取指定城市的天气信息,input_schema:{type:object,properties:{city:{type:string,description:城市名称}},required:[city]}}]# 2. 定义执行函数和 Tool 定义分离defget_weather(city:str)-dict:# 模拟天气查询return{city:city,temp:25,condition:晴}# 3. 发起请求responseclient.messages.create(modelclaude-sonnet-4-6,max_tokens1024,toolstools,# 每次请求都要传messages[{role:user,content:北京天气怎么样}])# 4. 手动处理 tool_use 回调ifresponse.stop_reasontool_use:forblockinresponse.content:ifblock.typetool_use:ifblock.nameget_weather:cityblock.input[city]resultget_weather(city)# 5. 手动发送 tool_resultresponseclient.messages.create(modelclaude-sonnet-4-6,max_tokens1024,toolstools,# 又要传一遍messages[{role:user,content:北京天气怎么样},{role:assistant,content:[block]},{role:user,content:[{type:tool_result,tool_use_id:block.id,content:str(result)}]}])print(response.content[0].text)痛点Tool 定义和执行逻辑分离维护时容易不同步每次 API 调用都要传 tools 参数浪费 Tokentool_use 回调需要手动匹配和处理换个应用如 Cursor就得重写一遍3.2 方式二MCP Server工具定义 执行一体化server.py MCP Server 方式 —— 工具定义和执行逻辑内聚在一起 一次编写Claude Desktop、Cursor、Continue 等都能直接用 importjsonfrommcp.serverimportServerfrommcp.server.stdioimportstdio_server serverServer(weather-server)# Tool 定义和执行逻辑在一起内聚且同步server.list_tools()asyncdefhandle_list_tools():return[{name:get_weather,description:获取指定城市的天气信息包括温度和天气状况,inputSchema:{type:object,properties:{city:{type:string,description:城市名称}},required:[city]}}]server.call_tool()asyncdefhandle_call_tool(name:str,arguments:dict):ifnameget_weather:cityarguments[city]result{city:city,temp:25,condition:晴}return[{type:text,text:json.dumps(result,ensure_asciiFalse)}]asyncdefmain():asyncwithstdio_server()as(read_stream,write_stream):awaitserver.run(read_stream,write_stream,server.create_initialization_options())if__name____main__:importasyncio asyncio.run(main())Claude Desktop 配置{mcpServers:{weather-server:{command:python,args:[C:/path/to/server.py]}}}优势Tool 定义和实现在一起修改时不会遗漏Client 通过 tools/list 自动发现Token 零开销tool_use 回调由 MCP Client 自动调度一次编写跨应用复用3.3 对比总结方面纯 Function CallingMCP Server代码量~50 行含回调处理~30 行Tool 定义与实现分离易不同步内聚同步更新跨应用复用每次重写一次编写到处使用Token 开销每次请求传 tools零自动发现回调处理手动匹配自动调度部署代码内嵌独立进程/服务面试加分点Function Calling 是模型能力MCP 是协议标准两者在不同抽象层MCP 的 stdio Transport 天然隔离无需处理端口冲突tools/list 实现工具发现避免了每次请求手动传入MCP 生态已有 1000 开源 Server可以不用重复造轮子MCP 支持 Tool/Resource/Prompt 三种原语比纯 Function Calling 覆盖更多场景四、选型指南4.1 什么时候用纯 Function Calling只有 1-2 个简单工具不值得起一个 MCP Server一次性的原型验证工具逻辑和业务代码强耦合不需要跨应用复用4.2 什么时候用 MCP工具有多个使用场景/应用工具逻辑复杂值得独立维护团队协作工具可共享给同事需要工具发现和动态注册能力构建企业内部工具体系4.3 最佳实践两者结合在生产环境中推荐架构是┌─────────────────────┐ │ 你的 AI 应用 │ │ (Claude API 调用) │ ← Function Calling 做推理 ├─────────────────────┤ │ MCP Client SDK │ ← MCP 做通信 ├─────────────────────┤ │ 企业 MCP Server │ │ ┌─────┐ ┌─────┐ │ │ │用户API│ │订单API│ │ ← 业务工具实现 │ └─────┘ └─────┘ │ └─────────────────────┘模型用 Function Calling 决定该查什么MCP 负责把请求路由到正确的 Server 并执行两者各司其职。五、总结Function Calling 和 MCP 的关系可以用一句话概括Function Calling 是模型的决策大脑MCP 是工具的通信高速公路。它们不是竞争关系而是不同层面的互补。Function Calling 回答该做什么MCP 回答怎么做到。推荐学习路径先用 Function Calling 跑通一个 API 调用理解模型如何决定调用工具把同一个工具改写为 MCP Server体验一次编写到处使用的便利探索 MCP 生态在 github.com/modelcontextprotocol/servers 学习优秀实践构建企业的 MCP 工具体系让所有 AI 应用共享同一套工具基础设施延伸阅读Anthropic Tool Use 文档MCP 官方规范MCP Python SDKOpenAI Function Calling 文档理解这两者的关系你就站在了 LLM 应用开发的最前沿。
