1. 什么是 MCP

MCP（Model Context Protocol，模型上下文协议）最早由 Anthropic 于 2024 年 11 月 25 日在文章《Introducing the Model Context Protocol》中提出。

它旨在定义一种标准，用于在应用程序与大型语言模型（LLM）之间交换上下文信息。借助 MCP，开发者可以以统一的方式将数据、工具和环境提供给 AI，让 AI 不再局限于“回答问题”，而是具备“执行任务”的能力。

你可以把 MCP 理解为 AI 的 Type-C 接口：就像 Type-C 让电脑能连接显示器、键盘、耳机一样，MCP 也让语言模型（如 Claude、GPT）能够标准化、安全地访问外部工具、文件、数据库和上下文资源。

MCP 的诞生源于解决 LLM 应用的一个关键限制，即它们与外部和数据源工具的隔离问题。 LLM 应用的一个核心关注点是数据传输，即如何将数据提供给 LLM 进行推理。这一直是 RAG 和微调的目标，同时也是 MCP 的目标。

2. 为什么需要 MCP？

在没有 MCP 之前，使用 AI 往往意味着用户需要手动搜集并打包所有上下文信息，一次性地通过 prompt 提供给模型，然后静待其生成回答。

这通常要求用户亲自查询数据库、搜索网页、复制粘贴内容，并将其组织成 prompt 格式。随着任务复杂度不断提高，用户对模型的期望也在上升——他们希望模型能直接访问文件、数据库、实时信息等外部资源，以提供更加准确、上下文相关的响应。

为满足这一需求，许多 LLM 平台陆续引入了 Function Calling：模型可以在运行时调用开发者注册的函数，实现自动获取数据或触发操作，从而显著提升交互性和自动化能力。

然而，Function Calling 本身也存在局限。各家平台（如 OpenAI、Google、Anthropic）虽都提供此能力，但缺乏统一标准，函数结构、调用协议各异，导致开发者必须为每个平台分别编写和适配工具逻辑，增加了维护负担和重复开发成本。

MCP（Model Context Protocol）正是为了解决这一碎片化问题而诞生。它定义了模型与外部工具之间的统一通信协议，相当于 AI 世界中的“万能插头”，为模型与现实世界之间架起一座标准化的桥梁。

相较于传统的 Function Calling，MCP 具有以下优势：

• ✅ 标准化接口：开发者可以使用统一格式为不同模型接入工具，无需重复适配。
• 🌱 生态丰富：已有众多第三方工具、组件和框架支持 MCP，生态逐渐成熟。
• 🔐 安全可靠：支持在本地或受控环境中执行工具调用，避免上传敏感数据。

3. 基本概念

4. MCP 架构和通讯机制

4.1 总体架构

MCP 遵循客 客户端-服务器架构，主机程序（如 Claude Desktop）可以连接多个后端服务（即 MCP 服务器），就像浏览器可以连接多个网站一样。

• MCP Hosts：像 Claude Desktop、IDE 或 AI 工具等程序，它们希望通过 MCP 访问数据。 宿主进程充当容器和协调器：
  • 创建和管理多个客户端实例
  • 控制客户端连接权限和生命周期
  • 执行安全政策和同意要求
  • 处理用户授权决策
  • 协调 AI/LLM 集成和采样
  • 管理跨客户端的上下文聚合
• MCP Clients：与服务器保持 1:1 连接的协议客户端。 每个客户端由主机创建并维护一个隔离的服务器连接：
  • 每个服务器建立一个有状态会话
  • 处理协议协商和能力交换
  • 双向路由协议消息
  • 管理订阅和通知

  • 维护服务器之间的安全边界 主机应用程序创建并管理多个客户端，每个客户端与特定服务器具有 1:1 的关系。

    

• MCP Servers：通过标准化的模型上下文协议暴露特定功能的轻量级程序。 服务器提供专门的上下文和功能：
  • 通过 MCP 原语公开资源、工具和提示
  • 独立运作，专注负责
  • 通过客户端界面请求采样
  • 必须尊重安全约束
  • 可以是本地进程或远程服务
• Local Data Source：计算机文件、数据库以及 MCP 服务器可以安全访问的服务。
• Remote Services：MCP 服务器可以通过 API 等方式连接到的互联网外部系统。

整体运行流程总结：

当你向 AI 提出问题时，流程是这样的：

• 提问 ➜ Host ➜ LLM ➜ MCP Client ➜ MCP Server ➜ 执行操作 ➜ 返回结果 ➜ LLM 生成回答 ➜ 展示答案

这样的架构设计可以让 LLM 更灵活地调用各种数据和工具。开发者只需专注于开发 MCP Server，用户也无需额外学习成本，就能获得智能化体验。

4.2 传输协议

协议目前定义了两种标准传输机制用于客户端与服务器通信：

1. stdio，标准输入和标准输出的通信
2. Streamable HTTP 可流式传输的 HTTP

客户端和服务端也可以以插件的形式实现自定义传输。

• 4.2.1 Stdio

  在 stdio 传输中，客户端将 MCP 服务器作为子进程启动。服务器从标准输入（ stdin ）读取 JSON-RPC 消息，并将消息发送到标准输出（ stdout ）。消息可以是 JSON-RPC 请求、通知、响应——或者包含一个或多个请求和/或通知的 JSON-RPC 批处理。

  stdio 传输是 MCP 最基础的传输方式，它通过标准输入输出流（stdin/stdout）进行通信：

  • Client → Server: 通过 stdin 发送 JSON-RPC 消息
  • Server → Client: 通过 stdout 返回 JSON-RPC 响应
  • stderr: 用于日志和调试信息输出

  每条消息都是独立的 JSON 行：

• 4.2.2 Streamable HTTP 传输

  TIP

  🚨 重要说明

  Streamable HTTP 是 MCP 协议 2025-03-26 版本中的正式传输方式，它替代了之前版本（2024-11-05）的 HTTP+SSE 传输。

  Streamable HTTP 基于 HTTP协议，可以选择性地使用 Server-Sent Events (SSE) 实现流式通信：

  核心特点：

  1. 统一端点: 服务器提供单个 HTTP 端点，同时支持 POST 和 GET 方法
  2. 灵活响应: 服务器可以返回简单 JSON 响应或 SSE 流
  3. 双向通信: 支持客户端到服务器和服务器到客户端的消息传

  消息交换模式

  Server 响应方式

  • 方式1: JSON 响应

  • 方式2: SSE 流响应

  Server → Client 通信

  服务器可以通过 GET 请求建立 SSE 流来主动发送消息：

  与之前版本的区别

  以下是两种传输方式的主要差异对比：

  特性	HTTP+SSE (2024-11-05)	Streamable HTTP (2025-03-26)
  端点数量	分离的 POST/SSE 端点	统一的 MCP 端点
  协议复杂度	相对复杂	简化统一
  灵活性	有限	高度灵活
  向后兼容	已废弃	支持向后兼容

4.3 基本消息类型

MCP 定义了基于 JSON-RPC 2.0 的三种核心消息类型：

• Requests: 双向消息，带有方法和参数，期望有响应
• Responses: 匹配特定请求 ID 的成功结果或错误
• Notifications: 无需回复的单向消息

4.4 能力协商

Model Context Protocol 使用了一种基于能力（Capability Negotiation）的协商机制，在初始化阶段，Clients 和 Servers 会明确声明它们支持的功能，而这些能力决定了在会话期间可以使用哪些协议特性和原语（primitives）

1. 初始化阶段
   1. Host 初始化 Client 启动一个 MCP 客户端，如加载一个插件、Agent、AgentUI。
   2. Client 请求初始化会话 Client 向 MCP Server 发起 describe 或 start_session 请求，询问有哪些 Agent、Tool、Context 可用。
   3. Server 返回支持的能力 Server 响应 Server 端具备的能力信息（模型种类、最大 token、支持的工具类型等）。
2. Client Requests 循环（用户侧的请求）
   1. 用户或模型发起操作 比如点击一个按钮、用户输入一句话，或者 Agent 逻辑决定调用某个工具。
   2. Client 构造请求并发送给 Server 请求中包含需要调用的 Tool、访问的资源（如文档、搜索、函数 API）。
   3. Server 处理并返回 Response MCP Server 调用对应工具（可能是插件、Web API、本地函数）并返回结果。
   4. Client 处理响应并反馈给 Host（更新 UI 或继续对话） 更新页面状态、填入回答，或进一步触发 Agent 推理。
3. Server Requests 循环（AI 推理请求）
   1. Server 请求采样 也就是请求模型进行语言生成（chat.complete / run.sample）。
   2. Client 将请求转发至 Host（语言模型） Host 通常包含模型推理能力（本地模型或 OpenAI API 等远程模型）。
   3. Host 生成回答并返回给 Client
   4. Client 再返回给 Server，继续任务流程

4.5 协议规范之基本消息类型

所有在 MCP clients 和 servers 之间的消息必须遵循 JSON-RPC 2.0 规范。该协议定义了三种基本类型的消息：

1. Request 消息请求

   请求由客户端发送至服务器，或由服务器发送至客户端，以启动一项操作，格式：

   • 请求必须包含一个字符串或整数 ID。
   • 与基础 JSON-RPC 不同，ID 不得为 null。
   • 在同一会话中，请求方不得重复使用之前已用过的请求 ID。

   业务类型：

   请求方法	发起方	响应方	描述
   initialize	Client	Server	初始化会话
   tools/list	Client	Server	发现可用的工具
   tools/call	Client	Server	调用工具
   resources/list	Client	Server	发现可用的资源
   resources/read	Client	Server	要获取资源内容
   resources/templates/list	Client	Server	发现可用的参数化资源
   resources/subscribe	Client	Server	订阅特定资源，并在其发生变化时接收通知
   prompts/list	Client	Server	发现可用的提示词
   prompts/get	Client	Server	要获取特定的提示词
   roots/list	Server	Client	列出 Server 有权限访问 Client 的文件系统 Root 节点，暴露目录和文件
   sampling/createMessage	Server	Client	使 Server 能够利用 AI 能力的生成能力

2. Response 消息响应

   Response 是对 Request 的响应，格式：

   • 响应必须包含与其对应的请求相同的 ID。
   • 响应进一步细分为 成功结果 或 错误。必须设置一个result或error。响应不得同时设置两者。
   • 结果可以遵循任何 JSON 对象结构，而错误必须至少包含错误代码和消息。
   • 错误代码必须是整数。

3. Notifications（通知）

   Notifications以单向消息的形式从客户端发送到服务器，反之亦然。接收方不得发送响应。

   通知不得包含 ID。

4. 举例：Client 获取 Server Tool 列表

   要查询可用的工具，Client发送一个 tools/list 请求。

   Request

   Response

4.6 生命周期

模型上下文协议 (MCP) 为 client-server 连接定义了严格的生命周期，以确保正确的能力协商和状态管理。

1. Initialization（初始化）：能力协商和协议版本协商
2. Operation（操作）：正常协议通信
3. Shutdown（终止）：正常终止连接

1. Initialization (初始化)

   初始化阶段 必须 是客户端与服务器之间的首次交互。在此阶段，客户端和服务器需完成以下操作：

   • 建立协议版本兼容性
   • 交换并协商功能能力
   • 共享实现细节

   客户端 必须 通过发送包含以下内容的 initialize 请求来启动此阶段：

   • 支持的协议版本
   • 客户端功能能力
   • 客户端实现信息

   初始化请求 必须不在 JSON-RPC 批处理中，因为在初始化完成之前无法发送其他请求和通知。这也允许与之前不明确支持 JSON-RPC 批处理的协议版本保持向后兼容。

   TIP

   简单说，就是初始化请求必须独立发送，不能和其他请求打包在一起，这样确保了协议的稳定性和兼容性。

   服务器 必须 返回其自身的功能和信息：

   初始化成功后，客户端 必须 发送一个 initialized 通知，以表示它已准备好开始正常操作：

   1. 1.1 版本协商

      在 initialize 请求中，客户端 必须 发送其支持的协议版本。这通常 应该 是客户端支持的最新版本。

      如果服务器支持请求的协议版本，它 必须 使用相同的版本响应。否则，服务器必须使用它支持的另一个协议版本进行响应。这 应该 是服务器支持的最新版本。

      如果客户端不支持服务器响应中的版本， 应该 断开连接。

   2. 1.2 能力协商

      客户端和服务器的能力确定会话期间将可用的可选协议功能。

      关键能力包括：

      类别	能力	描述
      Client	roots	提供文件系统根节点的能力
      Client	sampling	支持大语言模型（LLM）采样请求的功能
      Client	experimental	描述对非标准实验性功能的支持
      Server	prompts	提供提示词模板的功能
      Server	resources	提供可读取资源的功能
      Server	tools	暴露可调用工具的功能
      Server	logging	发送结构化日志消息的功能
      Server	experimental	描述对非标准实验性功能的支持

      能力对象可以描述子能力，如：

      • listChanged : 支持列表变更通知（针对提示、资源和工具）
      • subscribe : 支持订阅个别项目的变更（仅资源）

2. Operation (操作)

   在运行阶段，客户端和服务器根据协商的能力交换消息。

   双方 应该：

   • 尊重协商确定的协议版本
   • 仅使用成功协商的 Capability

3. Shutdown（关闭）

   在关闭阶段，一方（通常是客户端）会干净地终止协议连接。没有定义特定的关闭消息——相反，应使用底层传输机制来信号连接终止：

   • stdio 对于 stdio 传输，客户端 应该 通过以下方式发起关闭：
     • 首先，关闭子进程（服务器）的输入流。
     • 等待服务器退出，或在合理时间内未退出时发送 SIGTERM
     • 发送 SIGKILL ，如果服务器在合理时间内未启动，则发送 SIGTERM

   服务器 可以 选择通过关闭对其客户端的输出流并退出来发起关闭。

   • HTTP 对于 HTTP 传输，关闭相关的 HTTP 连接表示关闭。

4. Error Handling (错误处理)

   实现 应该 准备好处理这些错误情况：

   • 协议版本不匹配
   • 未能协商所需功能
   • 初始化请求超时
   • 关闭超时

   实现 应该 为所有请求实现适当的超时，以防止连接挂起和资源耗尽。

   示例：初始化错误：

5. MCP Server 的使用：以 Github MCP 为例

以 Cursor + Github 为例，体验让AI直接操作代码仓库：

步骤1：创建Github个人访问令牌

1. 访问 Github Token 设置页
2. 勾选 repo 和 workflow 权限
3. 生成以 ghp_ 开头的令牌字符串

步骤2：配置MCP Server

在 Cursor 按一下步骤打开 MCP 配置文件：

输入以下代码，并将 <YOUR_GITHUB_PERSONAL_ACCESS_TOKEN> 替换为你的 Github 的 Personal Access Token：

步骤3：验证连接

当状态指示灯变绿后，尝试自然语言指令：

当我们提出问题后，会发现 cursor 自动去使用 Github MCP 的 search_repositories 去搜索我的 Github 仓库。

然后使用了 5 次 git_file_contents 来获取每个项目的文件信息。

最后结合所有信息 cursor 给我们输出了最后的结果：

6. MCP Server 开发入门：以天气查询 MCP 为例

1. 创建项目

更新你的 package.json 以添加类型：“module”和构建脚本：

tsconfig.json在项目的根目录中创建一个：

2. 构建服务器

3. 调试

使用官方提供的调试器：