01 MCP初识

MCP协议简化了哪些流程？为什么需要MCP协议？

01. 什么是MCP？为什么需要MCP？

MCP 全称 Model Context Protocol，即模型上下文协议，起源于 2024 年 11 月 25 日 Anthropic 发布的文章：Introducing the Model Context Protocol，MCP 定义了应用程序和 AI 模型之间交换上下文信息的方式，这使得开发者能够以一致的方式将各种数据源、工具和功能连接到 AI 模型（MCP 并不是什么框架，也不是什么技术的突破，而仅仅一个中间协议层）。

以现实生活的 USB-C 为例，USB-C 可以让不同的设备能工使用相同的接口进行连接，例如：键鼠、音响、打印机、显示器等，MCP 的目标就是为了创建一个通用的标准，使 AI 应用程序的开发和集成变得更加简单和统一。

可以看出，MCP 犹如 AI 应用的“USB-C 端口”，使 LLM 能够通过统一的接口无缝连接至多种数据源和工具（如文件系统、数据库或外部 API），并且 MCP 基于 JSON-RPC（一种使用 JSON 编码的远程过程调用协议），无论是否是开发者使用起来都非常简单。

以前面我们实现的高德天气查询工具为例（链接：https://lbs.amap.com/api/mcp-server/gettingstarted），高德本身提供了 MCP Servers 服务，我们只需复制对应的 MCP 配置，如下：


{
  "mcpServers": {
    "amap-maps-streamableHTTP": {
      "url": "https://mcp.amap.com/mcp?key=您在高德官网上申请的key"
    }
  }
}

在支持 MCP 服务的客户端软件中添加配置，例如 Cherry Studio、Cursor、Claude Desktop 等，客户端即可识别到该 MCP Server 提供的所有工具。

想象一下没有 MCP，各个工具都有不同的 API，每个 LLM 都有不同风格的工具参数声明，需要为现有的各个工具都封装一段代码，并让 LLM 可以调用，要接入 100 个工具，就要封装 100 段代码，这是非常痛苦的（参考前面课时封装 calculator() 计算器）。

并且对于同一个 API，A 封装了代码，B 还需要反复封装，在代码上无法快速复用。而有了 MCP 之后，工具只要遵循了 MCP 协议，发布了对应的 MCP Servers，使用者哪怕不懂编程也可以按照规则，快速将对应工具接入到 LLM 中，实现外部环境的交互。

同时随着 MCP 生态的越发完善，越来越多的工具服务商、语言模型服务商也开始接入 MCP 生态，带来的优势也非常明显：

生态 – MCP 提供很多现成的插件，你的 AI 可以直接使用，无需编写任何代码。统一性 – 不限制于特定的 AI 模型，任何支持 MCP 的模型都可以自由切换，例如 GPT、Claude、DeepSeek 等。数据安全 – 你的敏感数据留在自己的电脑上，不必全部上传，（因为我们可以自行设计接口确定传输哪些数据）。操作建议 – 对于现有的 MCP 工具，无需编程基础，就可以快速将该工具接入到 LLM/Host 主机中，让普通人也可以借助 AI 便捷对接各类工具。

02. MCP 服务三个核心组件初识

那么问题来了，既然 MCP 这么好用，它的架构是什么样的呢？MCP 整体的内容非常多，但是核心组件可以简化成 3 个：

MCP Hosts：运行 MCP 的主应用程序，例如 Claude Desktop、智能 IDE 或 AI 工具，负责通过 MCP 访问外部数据。MCP Clients：协议客户端，与服务器建立一对一连接，负责发送请求并接收响应。MCP Servers：轻量级程序，通过 MCP 暴露特定功能（如文件读取或 API 调用）。

听起来有点抽象，我们可以通过一张时序图来快速了解 LLM+MCP 是如何工作的：

流程和常规的软件接入并没有太大区别，例如 Redis，也是在代码（Host）初始化一个 Redis 客户端，通过客户端连接 Redis Server 完成对应的业务逻辑，也是 Host-Client-Server 结构。

除此之外，有没有发现，和我们前面使用的 Tool Calls 很接近，但是接入 MCP 后，原先由我们本地代码维护的工具说明、工具调用，变成了统一由 MCP Client 维护（工具参数的获取、工具信息的调用等），并提供统一的 API：

甚至是在实现 MCP 架构后，整个系统可以通过配置化的方式来快速接入额外的工具，而不需要每一次扩展工具都重新编译构建代码。

03. MCP 和 Tool Calls 的区别

Tool Calls 是一种机制，它告知 LLM 有哪些工具可供使用，随后 LLM 根据用户的 Prompt 决定需要调用哪些特定工具。然而，LLM 本身并不具备直接调用这些工具的能力，这就需要依靠本地代码（传统做法）、MCP host（如 Cursor 或 Cherry Studio 等应用）通过 MCP client 和 MCP server 的交互来实现实际调用。

诚然，即使没有 MCP 也能实现工具调用功能，但这样一来，每种工具的调用方式都需要单独实现，这正是缺乏标准化带来的问题。

以一个具体场景为例： 假设你希望 LLM 告诉你未来一周北京的天气情况，你有两个可用的工具：

一个是“获取特定地点和日期的天气信息” (get weather with locations and date)另一个是“获取当前时间” (get current time)。

在没有 MCP 的情况下，你需要在代码中预先编写如何调用这两个功能，然后在 LLM 需要时分别触发调用。而有了 MCP 之后，你只需配置好相应的 servers，便可通过统一的方式进行调用，区别仅在于传递的参数不同。

包括在 MCP 中，我们也可以通过 tools/list 指令获取 MCP Servers 提供的所有工具的描述信息，并将这些信息组装成 Tool Calls 的格式，或者以 prompt 的形式让 LLM 格式化输出实现工具调用（Claude 官方示例代码的做法，严重依赖 LLM 的能力）。

以 高德MCP工具 为例，使用 POST 方法向 https://mcp.amap.com/mcp?key=您在高德官网申请的key 传递如下数据：

JSON


{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {
    "cursor": "optional-cursor-value"
  }
}

这是图片中识别出的文字内容，包含 JSON 代码块和底部的说明文字：

得到响应如下：

JSON


{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "{"city":"广州市","forecasts":[{"date":"2025-09-24","week":"3","dayweather":"大雨","nightweather":"中雨","daytemp":"26","nighttemp":"24","daywind":"东北","nightwind":"东北","daypower":"6","nightpower":"6","daytemp_float":"26.0","nighttemp_float":"24.0"},{"date":"2025-09-25","week":"4","dayweather":"中雨","nightweather":"雷阵雨","daytemp":"29","nighttemp":"24","daywind":"东","nightwind":"东","daypower":"1-3","nightpower":"1-3","daytemp_float":"29.0","nighttemp_float":"24.0"},{"date":"2025-09-26","week":"5","dayweather":"多云","nightweather":"晴","daytemp":"33","nighttemp":"25","daywind":"北","nightwind":"北","daypower":"1-3","nightpower":"1-3","daytemp_float":"33.0","nighttemp_float":"25.0"},{"date":"2025-09-27","week":"6","dayweather":"多云","nightweather":"多云","daytemp":"33","nighttemp":"25","daywind":"北","nightwind":"北","daypower":"1-3","nightpower":"1-3","daytemp_float":"33.0","nighttemp_float":"25.0"}]}"
      }
    ],
    "isError": false
  }
}

当然，MCP 协议除了约定工具相关的信息之外，还提供了 Resources (资源) 和 Prompts (提示词) 相关的资源管理，这部分在下节课我们会详细讲解。从上述从这里就可以看出 MCP 和 Tool Calls 是完全不同层面的东西，是两条并行的赛道，它们不互为前提条件，你可以各取所需。

MCP 是一个抽象层面的协议标准。它规定了上下文与请求的结构化传递方式，并要求通信格式符合 JSON-RPC 2.0 标准。Tool calls 则是某些大模型（如 OpenAI 的 GPT-4）提供的特有接口特性，当然目前绝大部分模型该接口均兼容 OpenAI。

应用可以选择在 MCP 之上通过特定机制（包括 Tool calls）与模型交互，也可以在 MCP 范式下使用其他不基于 Tool calls 的方式（例如使用 Prompt）与模型或数据源交互。

文章版权归作者所有，未经允许请勿转载。如内容涉嫌侵权，请在本页底部进入<联系我们>进行举报投诉!

THE END