一、MCP到底是什么#

MCP 是 Model Context Protocol 的缩写，最早由 Anthropic 提出。其作用可以理解为一种 「接口协议」，让 LLM 能够和外部的各种工具、数据库、服务进行交互。

但光看这一段定义，实际上我自己是很迷糊的，我想知道的是，一个只能预测文本tokens的模型，到底是如何调用一个外部API呢？

调用MCP的基本流程大概有五步：

第1步：准备阶段-向 LLM 提供工具调用说明

在用户与LLM开始对话之前，开发者会先将所有可用的工具（API、函数）按照特定格式（例如JSON Schema）定义好，并作为一条特殊的“系统指令”（System Prompt）或上下文的一部分，发送给LLM。

这些说明看起来像这样：

{
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "query_weather",
        "description": "获取指定城市实时的天气信息",
        "parameters": {
          "type": "object",
          "properties": {
            "city": {
              "type": "string",
              "description": "城市名称，例如：北京"
            }
          },
          "required": ["city"]
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "book_flight_ticket",
        "description": "为用户预订从出发地到目的地的机票",
        "parameters": {
          "type": "object",
          "properties": {
            "departure_city": {"type": "string", "description": "出发城市"},
            "destination_city": {"type": "string", "description": "目的地城市"},
            "date": {"type": "string", "description": "出行日期，格式 YYYY-MM-DD"}
          },
          "required": ["departure_city", "destination_city", "date"]
        }
      }
    }
  ]
}

现在，LLM 已经知道了它有两个工具：query_weather 和 book_flight_ticket，以及如何使用它们。

be like 给大家一本教辅资料，先看定义和例题，然后照葫芦画瓢去做练习题

第2步：分析并产生调用意图

用户输入一个指令，例如：“帮我查一下北京今天的天气怎么样？”

LLM在它庞大的语言知识和刚刚收到的工具说明书的共同作用下，进行推理：

1. 用户的意图是“查询天气”。
2. 我拥有的工具里，有一个叫 query_weather 的工具，它的描述是“获取指定城市实时的天气信息”，正好匹配。
3. 这个工具需要一个 city 参数。
4. 用户的输入里提到了“北京”，可以作为 city 参数的值。

因此，LLM 会生成一段文本，而这段文本恰好是一个结构化的 JSON，代表了它想要调用的工具和参数。LLM的输出会是这样的（这不是最终给用户的回答，而是一个中间步骤）：

{
  "tool_calls": [
    {
      "id": "call_abc123", // 一个唯一的调用ID，用于后续匹配结果
      "type": "function",
      "function": {
        "name": "query_weather",
        "arguments": "{\"city\": \"北京\"}" // 参数被序列化为JSON字符串
      }
    }
  ]
}

第3步：MCP框架解析并执行

我们的应用程序后端（MCP框架或者别的什么代码）会接收到 LLM 在上一步生成的这个 JSON。

1. 解析：程序看到 tool_calls 字段，知道这是一个工具调用请求。
2. 定位：它根据 name: "query_weather" 找到本地真正定义的Python函数 def query_weather(city): ...。
3. 传参并执行：它解析 arguments 里的 "{\"city\": \"北京\"}"，得到参数 city="北京"，然后执行 query_weather("北京")。
4. 获取结果：这个函数可能会去调用一个真实的天气API，然后返回一个结果，比如：{"temperature": "25°C", "condition": "晴"}。

第4步：结果返回 - 将执行结果喂回给LLM

MCP框架将第4步的执行结果，连同之前的调用ID，再次打包成一个结构化的信息，发送给LLM，以继续刚才的对话。

第5步：整合回答 - LLM生成最终的自然语言回复

LLM现在收到了新的信息。它会基于全部的上下文（原始问题 + 它的调用决策 + 工具的返回结果）来组织最终的回答。它看到：

1. 用户问了北京天气。
2. 我决定调用query_weather工具。
3. 工具告诉我结果是 {"temperature": "25°C", "condition": "晴"}。

于是，它生成了对用户友好的、最终的自然语言回答：“北京今天的天气是25摄氏度，晴天。”

二、MCP 的能与不能#

现在，我们知道了MCP的原理，那它到底能做什么，和做不了什么呢？

三、简单的开发感悟#

在讨论了 MCP 宏大的技术原理和能力边界后，我想结合自己开发一个简单 Todo-MCP 的心路历程，分享一些更接地气的感悟。这或许能解释，为什么一个看似简单的协议，在实际落地时会面临诸多取舍。

相关链接#

• Todo-PlanMCP
• 浅谈ChatGPT的记忆实现机制 兼论工程端记忆设计
• 关于酒馆SillyTavern所代表的伴侣模型系统的一些小思考