一文读懂MCP协议：它是什么以及AI Agent为何需要它呢

最近在研究AI Agent相关技术时，几个高频概念反复出现：Function Calling、Tools、MCP（Model Context Protocol）。

刚开始接触时，有一个问题始终绕不开：这些概念到底是什么关系？怎么从基础的函数调用，一步步走到了需要标准化协议的地步？

把这段时间的理解梳理出来，分享几点核心判断。

Function Calling：让 LLM 调用工具

先说说大语言模型（LLM）的一个基本事实：它本质上只能处理文本信息。

举个例子：用户说“帮我查查今天北京的天气”——LLM直接懵了，因为它既没有联网能力，也不知道当前时间。所以，必须给它装上“外设”，也就是Tools（工具）。

工具的本质，就是一个个可以执行具体功能的函数。比如：getWeather(city)、searchWeb(keyword)、queryDatabase(sql)。当用户提出问题，LLM判断自己无法完成，就会调用工具，获取结果，再生成最终回答。这个过程，就是Function Calling。

Function Calling 存在的问题

Function Calling虽然解决了LLM“能力有限”的问题，但工具一多，新麻烦就来了。

问题一：决策瘫痪

假设现在有searchGoogle()、searchWeb()、searchInternet()、querySearch()这些工具，功能都是搜索互联网。那么问题来了：LLM应该调用哪个？

如果工具描述不够清晰，模型很容易选错。这就是业界常说的“决策瘫痪（Decision Paralysis）”。

问题二：上下文过载

为了让LLM知道有哪些工具可用，需要把工具名称、描述、参数、返回值、使用方式一股脑儿传给模型。如果只有几个工具，倒还好说。但如果有100个、500个、甚至1000个工具呢？

这些工具描述都会挤进Context（上下文），导致三个后果：

• 占用大量Token
• 减少模型推理空间
• 增加调用成本

最终，工具越多，模型反而越难判断。

MCP 出现了

为了解决这些痛点，Anthropic提出了MCP（Model Context Protocol），中文叫“模型上下文协议”。

MCP 是什么？

MCP本质上是一套LLM与外部工具交互的标准协议。它规定了工具如何暴露、如何发现、如何调用，以及数据如何传输。

打个比方：以前每个AI平台都有自己的工具调用方式，就像不同国家用不同的插座；现在MCP就是统一了全球插座标准，所有工具都遵守这个协议。

MCP 的核心架构

MCP中主要有三个角色：MCP Client、MCP Server、Tool。关系清晰：用户→MCP Client→LLM→MCP Server→Tool。

MCP Client

负责与LLM通信，管理工具调用流程。典型代表包括Claude Desktop、Cursor、Trae。

MCP Server

负责管理工具、暴露工具能力。一个MCP Server可以提供天气查询、数据库查询、文件读取等多种工具。

Tool

真正执行任务的函数，比如getWeather()负责查询天气API。

MCP 提供了哪些能力？

MCP主要解决三个核心问题。

1. 工具搜索（Tool Discovery）

MCP Client可以向MCP Server请求“有哪些工具？”，Server返回工具列表及其描述、参数信息。这样一来，LLM就能知道当前有哪些能力可用。

2. 程序化工具调用

LLM不直接执行函数，而是通过MCP Client→MCP Server→Tool的流程，由MCP Server负责真正调用工具。

3. 工具使用示例

除了告诉模型“工具叫什么”，还可以告诉它“什么时候使用、参数怎么传、返回什么格式”，这能显著提高模型选择工具的准确率。

一个 MCP 请求流程

举个例子：用户在Trae中输入“帮我查询上海天气”。流程如下：

用户→Trae（MCP Client）→LLM→LLM判断需要天气工具→Trae请求MCP Server→调用weather Tool→返回天气数据→发送给LLM→LLM生成答案→展示给用户。

LLM 如何知道有哪些工具？

这是MCP最核心的问题。答案很简单：MCP Client主动向MCP Server获取工具列表。

流程：

第一步：MCP Client启动。

第二步：请求MCP Server的list_tools()方法。

第三步：MCP Server返回工具名称、描述、参数Schema。

第四步：MCP Client将这些工具信息配置到LLM的tools参数中。

LLM 如何知道应该调用哪个工具？

LLM并不直接认识工具，它依赖的是工具名称、描述和参数定义。比如工具getWeather的描述是“查询指定城市实时天气”，用户问“北京今天温度多少？”——LLM通过推理，发现用户需要天气信息，而getWeather的描述匹配，于是返回调用请求。

所以，工具描述的质量至关重要。

MCP 调用过程中的递归执行

实际Agent中，一次任务可能需要多轮调用。比如用户说“帮我分析最近销售数据”，可能需要：查询数据库→计算数据→生成报告。流程是：用户请求→LLM→需要数据库工具→调用MCP Server→返回数据→继续发送给LLM→LLM判断下一步→继续调用工具→最终回答。

这个过程会不断重复：messages追加→LLM重新推理→工具调用→messages合并，直到得到最终答案。

如何开发一个 MCP Server？

一个简单的MCP服务开发流程如下：

第一步：安装 SDK

pnpm i @modelcontextprotocol/sdk zod

其中，@modelcontextprotocol/sdk是MCP官方开发SDK，zod用于定义参数类型并自动生成JSON Schema。例如z.object({ city: z.string() })会自动转换为{ city: { type: "string" } }，让LLM理解工具参数。

第二步：创建 MCP Server

创建一个服务，作为工具管理中心。

第三步：注册 Tool

例如注册天气工具getWeather，包含名称、描述、参数和执行逻辑。

第四步：启动 MCP Server

让Client可以连接，比如Trae、Cursor、Claude Desktop。

第五步：开发 MCP Client 测试

测试是否可以获取工具列表、调用工具、正确返回结果。

面试回答：什么是 MCP？

MCP是Model Context Protocol，是一套标准化协议，用于统一LLM与外部工具、数据源、系统之间的交互方式。它解决了传统Function Calling中工具管理困难的问题，通过MCP Server暴露工具，让MCP Client获取工具定义并提供给LLM，最终实现模型对工具的发现和调用。

面试回答：MCP 有什么作用？

主要有三个作用：1. 标准化工具调用方式；2. 让LLM可以动态发现工具；3. 提高工具选择和调用准确率，减少上下文占用。

面试回答：你开发过 MCP 吗？怎么实现？

开发MCP Server时，首先安装@modelcontextprotocol/sdk和zod。然后创建MCP Server实例，通过Server注册Tool，使用zod定义工具参数，自动生成JSON Schema。启动MCP Server后，开发MCP Client获取工具列表并测试调用。整个流程就是：Client获取Tool信息，LLM根据描述选择工具，Client调用MCP Server，Server执行Tool，结果返回给LLM。

总结

一句话理解：Function Calling让LLM能调用工具，而MCP让LLM可以标准化、高效、准确地管理和调用大量工具。

未来AI Agent的核心能力，不是单纯让模型变聪明，而是LLM + Tools + MCP + Agent Workflow，共同组成真正能够完成复杂任务的智能系统。