关于MCP与Function Call的区别，近期在AI开发社区引发了大量讨论。此前我们在实际项目中大量采用Function Call模式，MCP刚兴起时，坦白讲我们也未完全厘清两者之间的本质差异。经过深入梳理，我们总结出一些关键区别，特此分享供参考。
Function Call
在大语言模型（LLM）中，Function Call本质上是一种让模型与外部工具、API或系统进行交互的机制。它使模型不仅能生成文本，还能执行具体操作——例如查询数据库、调用计算接口等。其核心工作流程如下：
- 首先定义Function Call需要调用的工具（Tools）。
- 用户输入时，模型根据输入内容匹配对应的工具定义，决定执行哪个工具。调用时的参数根据用户输入动态生成。
- 工具可以调用外部API（如查询天气），或读取本地文件（例如企业黑话汇总）。
- 模型根据工具返回的结果直接生成回复，也可以依据结果决定是否需要调用其他工具。
MCP
官方定义的MCP架构如下所示：
该架构抽象程度较高，若结合Function Call来理解，会更为直观：
从图中可以明显看出，最大的变化在于：工具（Tool）的定义被移出了应用层（Application）。具体而言，原来由API服务提供商负责的工作，现在变为他们定义工具并封装成一个MCP Server。例如，高德地图可将其地理编码、逆地理编码、路径规划等API封装成工具，对外提供MCP Server服务。
这样一来，应用开发者只需在自己的Application中实现一个MCP Client，根据模型的指令调用相应的MCP Server即可。原Application现改称为MCP Host。
MCP 的优势
极大简化应用开发工作量
假设应用需要对接100个API，采用Function Call方案需要手动实现100个Tool。而在MCP模式下，这些Tool由服务商提供，应用侧只需实现一个MCP Client即可。两者工作量差距显而易见。
更容易标准化
企业内部若存在多个团队，Function Call模式下各团队需自行实现Tool，实现方式五花八门。MCP则彻底统一了这一过程，为标准化提供了坚实基础。
提升 Tool 的可靠性与可复用性
Tool由服务商统一实现，供全球开发者使用，相比于每个Tool由不同开发者各自实现与维护，复用性显著提升。同时，由于统一封装，可靠性也得到增强。
增强 Tool 的易用性
若应用逻辑本身不复杂，甚至无需自行开发MCP Host和MCP Client。借助Cursor、CLine等工具，直接调用MCP Server即可完成。对于没有编程经验的使用者而言，这一门槛降低是实质性的。