通俗易懂的梳理MCP的工作流程（以高德地图MCP为例）

这两天专门研究了一下 MCP（Model Component Protocol），算是把整个流程梳理的差不多了。

首先，我们需要了解 MCP 旨在解决什么问题。

随着大型语言模型（LLM）能力的增强，它们不仅仅能生成文本，还能通过调用外部工具（APIs、函数等）来完成更复杂的任务，这通常被称为“工具调用” (Tool Use) 或“函数调用” (Function Calling)。

然而，不同的模型、不同的工具提供者可能有不同的实现方式，导致集成困难。

MCP 就是为了解决这个问题而提出的，它定义了一套标准化的协议，用于大模型、客户端应用（Client）和工具提供者（MCP Server）之间的交互。

具体到用户使用的角度。

应该使用哪个 MCP Server 并不是由 AI（大模型）决定的，而是由 client 决定的。

更准确的说，是你作为用户指定当前的 client 应该跟哪些 Server 做交互。

然后 AI 做的是从这些 MCP Server 提供的工具列表（tools list）中选择合适工具进行调用。

至于后面这一步，模型如何选择符合需求的工具的问题，其实就是原本大模型工具调用（tool use/function call）的那一套。

大模型分析用户需求跟某个工具（有对应的功能描述）是否匹配，如果匹配，就调用对应的工具。

举个例子

比如说高德地图提供的 MCP Server（amap-amap-sse），包含了 12 个具体的工具（例如用于骑行路线规划的 maps_direction_bicycling、驾车路线规划 maps_direction_driving、查询某地天气的 maps_weather 等等）。

每个工具都有对应的描述，用于辅助大模型判断其能力。

当我在某个 client 里面使用了这个 MCP（具体如何配置和使用这里先不展开，放到下文讲），并且大模型从 prompt 中分析到有相关的需求时，那么模型就会做出决定调用相关的工具，来完成任务。

比如下面的例子中，任务是让 AI 规划一个五一期间的旅游路线规划，有天气查询、制定路线等需求。

那么就会触发模型调用高德地图 MCP 中的 maps_weather 工具。

以及用于规划路径的 maps_direction_transit_integrated 工具等等。

具体的工作过程

接下来就以上面的情况为例，梳理下这个过程到底是如何实现的，重要的是 MCP 在整个过程中扮演什么角色。

1、Client 连接到 MCP Server

从用户角度通俗的理解，Client 就是兼容或支持 MCP 协议的 AI 应用，比如官方的是 Claude 客户端，第三方的有 Cursor、Cline、cherrystudio 等等 AI 应用。

Client 的作用是提供一个跟 MCP Server 建立一对一或一对多连接关系的平台，并作为用户与大模型及工具交互的界面。

以 Cline 为例（你可以在 VS Code，Trae 等工具中安装此插件并使用它），它提供了多种安装 MCP 服务器的方式，可以直接从市场里面一键安装。

或者手动配置安装，MCP 服务器的提供者会提供具体的安装方法，比如安装高德地图 MCP（通过 SSE 方式），在 configure 里面把下面这段命令复制进去就行了（注意提前申请高德地图的 key）。

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

安装并打开它之后，Cline 就完成了跟高德 MCP 的连接。

这个步骤里，是你（用户）配置它去连接一个或多个特定的 MCP 服务器。

具体建立连接的底层实现，就是 MCP 协议干的事情了。

比如官方给的例子通过命令行参数传递服务器脚本路径来实现，不过这是 Client 开发者要考虑的事。

总之，在这一步里，MCP 的作用就是提供协议来建立和维护这种 Client 和 Server 之间的连接。

2、Client 发现可用的工具

连接成功后，客户端代码会调用类似 session.list_tools() (以 Python SDK 为例）的函数。

连接的 MCP 服务器会返回它所有工具的列表，包括每个工具的 name、description 和 inputSchema（输入参数）等元数据。

MCP 的作用就是标准化 list_tools 请求和响应格式，确保任何客户端都能理解任何服务器提供的工具信息。

3、Client 为大模型准备 Prompt

当 Client 收到发送给它的问题/任务请求，比如，

制定一个五一期间南京 3 日游的行程，注意参考天气状况，重点是景点和美食，出行方式是公共交通

Client 要做的是将上一步发现的、当前已连接的 MCP Server 提供的可用工具列表（包含 name, description, inputSchema）包含在用户的请求 prompt 中，一起发送给大模型（LLM）。

4、大模型决定是否以及如何使用工具

大模型分析用户的问题，同时结合 client 在 prompt 中提供的工具描述来决定是否使用工具，以及使用哪个工具。

具体来说：

• • 如果问题可以直接回答，模型会直接生成文本。
• • 如果分析问题后需要外部信息或执行某个动作，并且这个需求与某个工具的 description 相匹配，LLM 就会判断需要使用该工具。
  例如，提问中需要查询天气，而 client 提供了一个 maps_weather 工具，其 description 为“根据城市名称或者标准 adcode 查询指定城市的天气”，LLM 就会决定使用它。
• • 然后模型会利用 inputSchema 来理解该工具需要哪些参数（比如城市名）。
• • 最后模型给客户端的响应会包含一个 tool_use 指令，明确指出要使用的工具 name 和所需的 input 参数。

在这个过程中，MCP 使得 client 能够将准确、标准化的工具描述（name, description, inputSchema）传递给模型，让模型能做出更准确的决策。

5、通过 MCP 执行工具

客户端代码接收到来自 LLM 的 tool_use 指令。

它提取出工具名称 (tool_name) 和参数 (tool_args)。

然后调用相应的 MCP 函数，例如通过 session.call_tool(tool_name, tool_args)。

这会向对应的 MCP 服务器发送一个标准化的 call_tool 请求，要求执行指定的工具并附带参数。

MCP 在此提供标准化的 call_tool 机制，让 client 能在不同的 Server 上以统一的方式调用操作。

6、MCP 服务器执行工具并返回结果

MCP 服务器接收到 call_tool 请求。

服务器根据请求运行对应的工具逻辑，类似这样：

然后将执行结果按照 MCP 协议规定的格式，发送回 Client。

MCP 协议保证了工具结果从服务器到客户端回传的标准化。

7、生成最终的回答

Client 收到来自 MCP Server 的工具执行结果后，会将这个结果再次发送给大模型。

大模型结合原始问题和工具返回的信息，生成最终的、更完整和准确的回答给用户。

总结

总结来说，client 应用负责管理跟 MCP Server 的连接、发现工具有哪些，并在 AI 大模型和 MCP Server 之间充当信使。

它将用户 prompt 和可用的工具信息发送给大模型。

至于具体的工具使用决策权，还是在于 LLM。

LLM 根据用户问题和收到的工具描述/格式，判断是否需要使用工具，以及使用哪一个。

这实际上也是 MCP 的核心价值：

MCP 并没有发明工具调用的概念，它只是围绕大模型的工具调用能力，提供了一套标准化的通信协议和框架。
这套标准包括了工具的发现机制、描述规范、调用协议和结果传递等，极大地促进了不同模型、客户端和工具服务之间的互操作性。

借一张图描述工具调用和 MCP 的比较：