简述 MCP

最近 MCP 的文章铺天盖地，言 MCP 则必称 AI 界的 USB-C、Function Calling 的标准化、工具调用协议。

翻阅 MCP Spec，你会发现 MCP 不只是工具调用标准化。

先科普几个 MCP 协议中的概念：

• MCP Server：工具调用、资源访问等服务的提供方
• MCP Client：与 MCP Server 建立连接，使用其能力的客户方
• Host：运行 MCP Client 的主体，如 AI 应用（如 Cursor、Claude Desktop）或 AI Agent。（通常不用太区别 Host 与 Client）

协议中定义的各种能力、服务存在于 Client 与 Server 的交互中，具体包括：

• Server 提供的能力，由 Client 调用：
• Tools：最常见也最容易理解的部分，为 LLM 工具调用能力。协议设计上工具由模型控制，模型会自主判断调用哪些工具，扩展能力。
• Resources：提供数据内容给 LLM。协议设计上资源由应用控制，可以自由定义资源的使用模式。可以让用户指定、程序内部控制或模型自己决定。
• Prompts：提供常用的 Prompt 模板。协议设计上 Prompt 由用户控制。用户根据意图显式选择提示词。
• Client 提供的能力，由 Server 调用：
• Roots：提供 Server 可以访问的路径列表，但不是强制的，有点像 robots.txt 的君子协定。
• Sampling：允许 Server 调用 Client 端的 LLM 进行一次问答。为 Server 提供大模型能力。
• Elicitation：2025-06-18 版本协议新加入的，本质是允许 Server 向 Client 请求要求用户回答问题。
• 其他细节如自动补全、消息通知、执行进度通知、分页、日志等

目前市面上的绝大部分 MCP Server 只提供 Tools，部分会尝试性引入 Resources 和 Prompts。Host 或 AI 应用作为 Client 的支持情况更差，很多都不支持 Resources 和 Prompts。可能是大家还没想到好的支持方式或用户交互设计。至于 Roots、Sampling 则更是基本没有 Host 实现。

这里存在奇妙的死锁，由于 Server 本身并不提供这些特性，Host 也就没有动力实现支持。反过来又导致 Server 开发者也没有实现这些特性的动力。

Demo

目前实现上述能力最全面的 Server 是 everything server：

• 启动命令为 npx -y @modelcontextprotocol/server-everything
• 这个 server 只是官方示例，并不提供真正有意义的功能

实现上述能力最全面的 Client 是 inspector：

• 启动命令为 npx -y @modelcontextprotocol/inspector
• 这是官方 MCP Server 调试工具

inspector 连接 server-everything 的效果图如下：

在 inspector 中可以通过点击测试 server-everything 上的各种 MCP Server 特性。

作为官方 Demo，这些示例的不足之处在于，虽然展示了各种能力的实现方式，但却没有很好地展示 Resources、Prompts、Sampling 这些能力到底应该在 AI 应用中如何提供给用户。能力有了，但还不知道该怎么用。

Claude Desktop

Prompt 在 MCP 协议 Spec 中的示例如下：

Prompt 模板

补全后的示例

从数据结构上可以看出，在 MCP 协议的设计上，补全后的 Prompt 应该直接以对话消息的形式注入到聊天历史中，开启下一轮对话，从而复用预先由开发者构造好的优质 Prompt。

Claude Desktop 作为 MCP 源头方开发的 AI App，实际上也没有充分应用 MCP 协议中的各项能力。目前也只实现了 Tools、Resources、Prompts 的基本使用。

且实现的还有点敷衍。比如 Resources、Prompts 的使用方法如下：

点击对话框上的 + 则可以选择 MCP Server 提供的 Resources 和 Prompts 模板。其中 Prompts 需要用户配合填入特定的参数。

完成后 Resources 和 Prompts 则会以上传文件的形式出现在对话内容中。

可以看出目前 Claude Desktop 并不区分 Resources 和 Prompts，也并未针对这两类特殊内容在对话中有针对性的处理，内容只是以简单的文本信息补入对话中。大模型实际并不能很好地针对性处理这些内容。

由于目前 Claude Desktop 的实现中 Prompt 与普通数据上传无异，会以 JSON 文本的形式插入到聊天内容中，对 AI 来说，会显得莫名其妙摸不着头脑。

只能僵硬地分析文件内容，无法真正当作 Prompt 来使用。

GitHub Copilot

所以 MCP 协议中的 Resources、Prompt、Sampling 到底是干什么的？应该怎么用？

在目前 MCP Spec 中列出的数十个 Host/Client 实现中，VS Code GitHub Copilot 是唯一一个实现了全部特性的 AI 应用（不算某些 Agent 框架）。

虽然某些交互还比较深比较奇怪，但确实实现了大部分 MCP 协议中定义的能力。仍以 everything MCP Server 试用 Copilot。

Resource

引用 Resource

选择 Resource 后会展示在这里

提交对话内容后的效果

Prompt

通过 / 可以展示出已经安装的 prompt 模板。（由于 VS Code 会自动加载 Cursor、Claude 等其他友商的 MCP Server 配置文件，所以工具列表显得有点杂且重复。）

点击后需要用户交互补全 Prompt 内容，补全后会直接展示在对话的编辑框中。

回车上屏后则执行 Prompt。

目前 Prompt 支持还不是很完整，比如一旦 Prompt 中同时包含 User + Assistant 的消息后，会变成这样。直接发给 AI 的话 AI 还是会迷茫。

Sampling

Sampling 这个词比较抽象，本质就是让 Server 可以调用 Client 的大模型能力。

everything 中提供的 sampleLLM 工具可以调用这个功能。在 Copilot 中进行测试。

会弹出对话框要求用户确认，允许 Server 调用大模型。

确认后执行工具。

整体执行逻辑是：

1. 用户自然语言要求 Server 调用 sampleLLM 工具
2. Client 调用工具 sampleLLM，通过工具的参数向 Server 传入用户的问题
3. Server 通过 Sample 接口，调用 Client 的大模型获取答案
4. Server 通过 sampleLLM 的返回值回复结果给 Client
5. Client 将工具结果展示给用户

通过 Sample 的能力，本身不带大模型的 Server，得以回答李白是谁这个相当宽泛的问题。

再谈 MCP

前面说了很多，也测试了很多，但仍有很多 MCP 协议中的细节没有介绍完整。

但已经可以看到 MCP 的野心远非仅仅是替代 Function Calling。

• 标准化 Function Calling 仅仅是 MCP Tools 所做的事，抽象来说，是标准化了 AI 调用工具的接口。
• Resources 是标准化了 App、AI、人在数据引用上的接口。
• Prompts 则是提供人和 AI 应用交流的接口。
• Sampling 则提供了程序工具调用 AI 的接口。
• Elicitation 则提供了工具向人类获取数据的接口。

Model Context Protocol (MCP) 正如其名，围绕着大模型，将人、工具、应用整体构建一个相对标准化的交互方式。从这个角度看，MCP Server 未来大概率不仅仅是工具的封装，而应该是完整的 AI Agent 的封装：

• Tools 表示 Agent 的能力
• Resources 表示 Agent 提供的资源数据
• Prompts 指示 Agent 的使用方式
• Sampling 为 Agent 提供大模型能力
• Elicitation 为 Agent 引入 Human-in-the-loop 流程
• （脑洞一下：感觉还缺一个定义工作流的环节，虽然 Prompt 也能在一定程度上完成这件事，但还不够严格和规范化）

如果发展趋势持续下去，未来 MCP 协议本身很可能会扩展覆盖掉 A2A、AG-UI 等协议。

至于前面提到的死锁，GitHub Copilot 已经成为了打开局面的第一人。当真正有 Host 支持了这些能力，那么 Server 就有理由去利用这些能力发挥更强的作用。当 Server 实现了这些能力，各大主流 Host 必然也要补齐相应能力。

死亡螺旋与增长飞轮一体两面，结果会是如何？