在谈MCP原理前，我们先谈谈MCP的技术前身—Function Calling。

1.Function Calling技术

在FunctionCalling技术出现之前，大语言模型虽然拥有强大的知识储备和语言理解能力，但是只能提供自身数据库已有的信息，无法和外界进行信息交互。它们的知识库更新速度有限，⽆法获取最新的实时信息，如天气、实时热搜事件等；也无法根据用户的特定需求提供个性化服务，只能提供通⽤的信息。为了解决这些问题，OpenAI在2023年推出了FunctionCalling，实现了让大模型通过函数调用外部工具，FunctionCalling的工作大致如下：

当用户向大模型提问时，大模型通过自然语言理解和推理，判断是否需要调用工具
如果需要调用工具，还会判断具体调用哪个工具，并自动组织参数，然后调用工具
然后拼接工具返回的结果，重新组织答案，回复用户

例如，如果用户问：

杭州今天天气怎么样？" 大模型可能调用 get_current_weather，并自动填充 location="杭州"和current_date="2025-07-14"

大致流程图如下：

因此相比传统的工程代码开发，它有几个优势：

结构化输出：确保模型能以预定义的 JSON 格式输出函数所需参数，提高了可解析性和可靠性，不需要开发额外的协议。

函数定义明确：通过schema清晰定义函数名称、描述、参数类型等

降低解析复杂度：开发者只需要解析 json 返回即可，不需要编写复杂的文本解析逻辑

提高准确性：减少了模型在生成函数调用时的"幻觉"问题

简化开发流程：标准化了大模型与外部工具的交互方式

Function Calling 和传统工程调用外部工具实现逻辑的差别有以下几点：

协议层面：传统代码需要自己设计 Tool 的描述协议并维护在提示词中，Function Calling 通过统一的 JSON 协议，约定函数定义和模型返回，方便维护。

实现层面：传统代码需要实现对应的工具调用和解析逻辑，同时也要维护提示词，通过 Function Calling 实现则不需要做文本返回的解析，也不需要将 Tools 放到提示词中维护。

效果层面：传统工程代码方式容易受限于模型的指令遵循能力，需要写很多代码兜底不可控的模型返回，FC能够做到较好的指令遵循。

综上Function Calling 提供了一种更智能、更灵活的工具调用范式。

尽管 Function Calling看起来很强大，但不是所有的大语言模型都支持 Function Calling，因为模型要支持 Function Calling 通常需要专门的训练或微调，需要在预训练或者微调阶段训练模型理解函数模式，学习如何生成符合预期格式的 json 输出，以及理解参数类型和约束条件等，所以 Function Calling 比较依赖模型的理解能力。且当下没有统一的行业标准，每个大语言模型提供商的实现方式不同，需要开发者为每种模型或工具编写特定的适配代码。比如扣子平台的墨迹天气，豆包能调用，并不意味着deepseek能直接调用，还需要针对deepseek重新适配。但至少通道建立起来了，有通道就要有协议，于是标准化又开源的 MCP 协议横空出世。

2.MCP的出现

Anthropic 在2024 年11月25日发布了MCP（Model Context Protocol），它是一种模型上下文协议，它允许大语言模型通过协议与外部⼯具或服务交互，动态获取实时数据或执⾏操作。意思就是只要工具按照这种协议开发，所有的大模型都能直接调用，不依赖模型的理解能力。

2.1 MCP的架构

MCP遵循客⼾端-服务器架构（client-server）

MCP主机（MCP Hosts）：装了Mcp的LLM应⽤程序（如ClaudeDesktop、Cursor、Cherry-Studio等）。
MCP客⼾端（MCP Clients）：在主机程序内部，与MCP server保持1:1的连接。
MCP服务器（MCP Servers）：为MCP Client提供上下文、工具和prompt信息。
本地资源（Local Resources）：本地计算机中可供MCP server安全访问的资源（例如⽂件、数据库）。
远程资源（Remote Resources）：MCP server可以连接到的远程资源（例如通过API）