MCP协议，换皮的工具调用？

1217 字
6 分钟
MCP协议，换皮的工具调用？
2025-04-04
科研学习
LLM
/
MCP
/
Agent
浏览量加载中...

0. MCP 的前世: Function Calling#

假如有一个函数 get_weather(location) ，传统的客服机器人的做法是：

  1. 接收用户输入（e.g. 帮我查一下杭州今天的天气）；
  2. 关键词提取/匹配或 NLP 等较为繁琐的转换来匹配程序员写的后端逻辑
  • e.g.if (keyword === 'weather') return await get_weather("杭州");）
  1. 后端调用 get_weather() 返回结果给前端。

LLM 提供了强大的自然语言理解能力，而 Function Calling 的目标就是非结构化的自然语言描述 →\rightarrow 函数调用。现在的处理流程变为：

  1. 前端接受用户输入；
  2. 后端携带用户提示和工具参数给 LLM；
  3. LLM 返回需要被调用的工具列表（意图识别）；
  4. 后端执行工具的具体逻辑，并将返回结果和用户输入再传递给 LLM；
  5. LLM 润色后返回最终结果给后端；
  6. 用户接收到输出；

1. MCP 时代#

1.1 Why MCP?#

Function Calling 虽然阐述了如何与大模型进行信息交换，但没有明确，还停留在具体情景具体代码实现层面。例如，假如你要开发一个 LLM Chat APP，你需要在你的 Server 上实现工具来调用外部服务，例如天气查询 API，同时你的工具还需要注册到大模型服务商的API 中，来完成工具调用的整个流程，工具注册、工具调用、结果返回等都需要你自己去实现，开发者需要关注的点过多，开发成本较高。

相比之下，MCP 提出了一个 Protocol 来定义，这样开发者只需要关注 MCP 工具包的接口，不需要关注具体数据交换的数据流了。APP 的 Server 充当 MCP Client 的角色，工具注册和调用的流程由 MCP Server 来完成，面向应用开发者，无需关注 MCP Server 内部如何实现。

正如标题所言，MCP 协议被不少人诟病的点是其似乎只是对 Function Calling 的换皮，但不能完全等同两者，两者是互补的，关键区别在于工具由谁来实现。

1.2 What MCP do?#

MCP 的目的主要是方便进行工具调用，我们先通过以下时序图回顾一下 MCP 协议做了什么。

当前 MCP 主要做的是通过标准化 MCP Server 实现，使 LLM 能够与本地和远程资源进行交互。但 MCP 本身还主要围绕在对服务器的规定，包括客户端如何发现和注册工具（上图中的工具注册阶段）和如何调用工具。

作为开发者，亟待解决的一点是标准化 MCP Client 与 MCP Server 的交互方式（例如 Standard I/O, HTTP or WebSocket），当前 MCP 协议并没有对这一部分进行规范，导致开发者需要适配不同 MCP Server 的接口来实现工具调用的功能。

从上图中的数据通路可以看出，MCP Client 和 MCP Server 间主要有以下几种消息功能：

  • ListToolsRequest/ListToolsResult：工具注册和发现的请求和结果；
  • CallToolRequest/CallToolResult：工具调用的请求和结果；

下图示例会更加直观：

1.3 MCP 的局限性#

  • MCP Client 还需要主动去适配这些 MCP Server，无疑增加了复杂度。
  • 实际场景中往往不止需要一次、或者一类工具调用，可能需要循环与用户对话，并调用多个 MCP Server 的工具，但 MCP Client 与 MCP Server 的交互，MCP Client 与 LLM 交互的标准也没有统一，MCP 协议只是关注于标准化单次的工具调用。

Thinking:

  • 统一 MCP Server 暴露的接口，类似 HTTP Stream。
  • 统一大模型与 Client 交互的方式，比如 Prompt 的格式。
  • 大模型并不调用工具，而是由 MCP Server 或软件系统调用工具执行获得结果再传递给大模型。这里事实上涉及两次与 LLM 的交互，第一次是获得需要调用的工具和参数（意图识别），第二次是获得结果再传递给 LLM 生成回答。统一暴露给客户端的接口，即生成完整的回答，同时这种方式还有没有优化空间？

2. How to develop MCP?#

很多主流编程语言都已经开发了针对 MCP 协议的 SDK，这里以 Python SDK 为例：

@mcp_tool(
  name="get_weather",
  description="Get the weather information for a given location"
)
def get_weather(location: str) -> str:
  # 这里是工具的具体实现逻辑，例如调用天气 API 获取天气信息
  return f"The weather in {location} is sunny with a high of 25°C."

3. 针对 MCP 的常见误区#

  1. MCP Server 的几个关键要素：
  • 工具由模型控制：模型决定何时调用工具，并使用工具返回的结果；
  • 资源由 APP 控制：APP 负责提供资源；
  • Prompt 由用户控制：用户决定是否要使用提示词；

文章分享

如果这篇文章对你有帮助，欢迎分享给更多人！

MCP协议，换皮的工具调用？
https://blog.yokumi.cn/posts/notes-about-model-context-protocol/
作者
Yokumi
发布于
2025-04-04
许可协议
CC BY-NC-SA 4.0
一些有关Game Theory(博弈论)的学习记录
RAG（Retrieval-augmented generation）个人学习笔记
相关文章智能推荐
1
MCP vs. Skill 旧瓶装新酒这一块
科研学习我在之前对 MCP 的学习中简单提到过当时 MCP 的一些痛点，不过发展到现在 MCP 这套通信协议已经被 Anthropic 搞得相当完善，MCP Server 也能快速适配到不同 Client。 从本质上来说，MCP 的功能侧重于包装了 Function Calling（函数调用），用户不需要具体 Tool 的逻…
2
Workflow 还是 Agentic？
科研学习Workflow（工作流），简单来说，一系列对 LLM 的调用，旨在通过预定的一系列步骤来解决特定问题。可以理解为用 DAG（有向无环图）把 LLM 节点连起来。市面上一些可视化拖拽式 Agent 开发平台，例如 Coze、Dify 等，基本上都是基于 Workflow 的设计思路来实现的。
3
写好提示词
科研学习Prompt Engineering = improving prompts to get more reliable, higher-quality outputs from language models. Key components = Action verb at start + direct task s…
4
RAG（Retrieval-augmented generation）个人学习笔记
科研学习传统的 LLM 模型主要存在以下 2 个问题： RAG 可以通过结合基于检索和生成模型的优势来提供更准确和上下文相关的响应，可以添加自己的预料构建知识库。 理论上，对于需要外挂知识库，即需要处理大量文本数据的场景，不通过微调，将这些文本数据全部塞进 Prompt 未尝不可，但：
5
2026.5 Live Repo
生活杂谈翻了翻相册才发现上一次已经是去年 9 月的羊文学了，哎gszm坏事做尽。 这回的出行方式是经典京沪高铁二等座，去年锅贴得意之作绿皮 D9 真给我坐麻了，这次果断 G 系列。不过被课表背刺，本来还可以买早一班（），结果就是快 0 点才到虹桥。好像是第一次这么晚到沪国。

评论区

分享你的想法，与大家交流讨论

文章目录
1
0. MCP 的前世: Function Calling
2
1. MCP 时代
1.1 Why MCP?
1.2 What MCP do?
1.3 MCP 的局限性
3
2. How to develop MCP?
4
3. 针对 MCP 的常见误区