1. 概述

官方网站
GitHub 仓库

模型上下文协议（Model Context Protocol，MCP）是一种开放协议，可实现大语言模型（LLM）应用与外部数据源和工具之间的无缝集成。

借鉴了语言服务器协议（LSP） 的设计思想，LSP 标准化了如何在整个开发工具生态系统中添加编程语言支持。类似地，MCP 标准化了如何将额外上下文和工具集成到 AI 应用生态系统中。

MCP 为应用提供了标准化方式，用于：

• 与语言模型共享上下文信息
• 向 AI 系统暴露工具和能力
• 构建可组合的集成与工作流

USB-C （也就是Type-C）规范让所有硬件设备实现了跨品牌、跨品类无障碍互通，可以把 MCP 想象成 AI 应用的 USB‑C 接口，各类 AI 应用，都能通过它标准化地对接外部系统、工具、数据，不用每个 AI、每个外部系统都单独做适配，MCP 统一了 AI 与外部世界的连接。

MCP 由 Anthropic 公司于2024 年 11 月 25 日正式公开发布并开源，后续捐赠给了 Linux 基金会旗下的 AI Agent Foundation（AAIF）进行中立治理。

MCP 由多个协同工作的核心组件构成：

• 基础协议：核心 JSON-RPC 消息类型
• 生命周期管理：连接初始化、能力协商与会话控制
• 授权：基于 HTTP 传输的认证与授权框架
• 服务器功能：服务器对外暴露的资源、提示模板与工具
• 客户端功能：客户端提供的采样与根目录列表
• 实用工具：日志、参数补全等通用横切功能

MCP 采用日期型版本号作为规范正式版本，目前最新稳定版为 2025-11-25 ：

MCP 社区为主流开发语言提供了官方 / 社区维护的 SDK：

• TypeScript SDK
• Python SDK
• Java SDK
• Kotlin SDK
• C# SDK
• Go SDK
• PHP SDK
• Ruby SDK
• Rust SDK
• Swift SDK

2. 核心架构

MCP 采用标准主机-客户端-服务器架构，主要参与者包括：

• 主机（Hosts）：发起连接的 AI 应用
• 客户端（Clients）：主机应用内部的连接器
• 服务器（Servers）：提供上下文和能力的服务

它们之间基于 JSON-RPC 进行通信：

2.1 主机（Host）

MCP 主机表示真正使用上下文的 AI 应用，比如，Claude Code、你自己开发的 AI Agent、Spring AI 封装的企业应用等。它不直接跟 Server 通信，只跟 Client 交互。

主要承担以下职责：

• 创建并管理多个客户端实例
• 控制客户端的连接权限与生命周期
• 执行安全策略与授权相关要求
• 处理用户的授权决策
• 协调人工智能/大语言模型的集成与采样工作
• 管理多客户端的上下文聚合

2.2 客户端（Clients）

MCP 客户端是 Host 与 Server 之间的通信桥梁，由 Host 创建，它不做 AI 推理，只做连接、请求、转发、适配。屏蔽底层通信细节，让 Host 无需关心 Server 在哪、如何连接。每个客户端均由主机创建，可创建并管理多个客户端，且与服务器维持独立一对一的连接。

主要承担以下职责：

• 为每个服务器建立一个有状态会话
• 处理协议协商与能力交换
• 双向路由协议消息
• 管理订阅与通知机制
• 维护不同服务器之间的安全边界

客户端向服务器提供的功能：

• 采样（Sampling）：服务器发起的智能体行为与递归 LLM 交互
• 根目录（Roots）：服务器发起的 URI 或文件系统边界查询，用于限定操作范围
• 信息获取（Elicitation）：服务器发起的向用户请求额外信息的请求

2.2.1 根目录（Roots）

根目录用于定义服务器的文件访问边界，明确服务器可读写哪些目录 / 文件。服务器可主动获取根目录列表，并在列表变化时收到通知。

交互流程图：

2.2.2 采样（Sampling）

采样是 MCP 为服务器提供的、通过客户端调用 LLM 生成内容的标准化能力（文本 / 音频 / 图像生成）。该流程让客户端保持对模型访问、选型与权限的控制，同时让服务器能够使用 AI 能力，且服务器无需持有任何 API 密钥。

交互流程图：

2.2.3 信息获取（Elicitation）

MCP 为服务器提供标准化方式，允许其在与客户端的交互过程中，通过客户端向用户请求额外信息。该流程让客户端保持对用户交互与数据共享的控制，同时支持服务器动态获取必要信息。

信息获取支持两种模式：

• 表单模式：服务器可向用户请求结构化数据，支持通过可选 JSON 模式校验响应
• URL 模式：服务器可引导用户访问外部 URL，完成不得经过 MCP 客户端的敏感交互

表单模式流程：

URL 模式流程：

2.3 服务器（Servers）

MCP 服务器提供专属的上下文信息与能力支持，所有 AI 需要的外部能力、数据、工具都在这里。比如，提供业务数据、文件系统服务、数据库服务、企业内部业务系统、第三方 API 服务等。

核心特性：

• 通过 MCP 原语暴露资源、工具与提示模板
• 独立运行，承担聚焦且明确的职责
• 通过客户端接口发起采样请求
• 必须遵守安全约束规则
• 可为本地进程，也可为远程服务

服务器向客户端提供的功能：

• 资源（Resources）：供用户或 AI 模型使用的上下文与数据
• 提示模板（Prompts）：面向用户的模板化消息与工作流
• 工具（Tools）：供 AI 模型执行的函数

2.3.1 提示词模板（Prompts）

MCP 为服务器提供标准化方式，向客户端暴露提示模板；提示模板是服务器预定义的结构化消息与指令模板，核心用于标准化引导大语言模型的交互逻辑，让模型按统一规则完成对话、生成等操作。

交互流程图：

2.3.2 资源（Resources）

MCP 为服务器提供标准化方式，向客户端暴露资源；这类资源的核心用途是为大语言模型提供交互所需的上下文数据，助力模型基于具体数据完成响应与处理，典型示例包括文件、数据库模式、应用专属信息等。

交互流程图：

2.3.3 工具（Tools）

MCP 允许服务器对外提供可由大语言模型调用的工具，作为模型与外部系统交互的标准化能力。支持模型与外部系统联动，例如：查询数据库、调用 API、执行计算等。

交互流程图：

2.3.4 其他能力

Server 端还提供一下能力：

• 补全（Completion）：补全是 MCP 为提示模板、资源模板参数提供的自动建议能力。
• 日志（Logging）：服务器可向客户端发送结构化日志消息，并遵循 RFC 5424 标准日志级别。
• 分页（Pagination）：用于处理资源、提示、工具等列表接口的大量结果返回场景，采用不透明游标式分页。

3. 核心组件

3.1 JSON-RPC

MCP 基础协议是整个模型上下文协议的底层骨架，基于 JSON-RPC 2.0 构建，通过有状态连接和能力协商，实现客户端与服务器之间安全、标准化、可扩展的交互。

JSON-RPC 2.0 是 轻量级、无状态、跨语言的远程过程调用（RPC）协议，使用纯 JSON 做数据交换，是整个 MCP（模型上下文协议）的底层消息标准。

三类标准消息：

• 请求
• 响应
• 通知

请求由客户端发往服务器，或由服务器发往客户端，用于发起操作。有以下要求：

• 请求必须包含字符串或整型 ID。
• 与基础 JSON-RPC 不同，该 ID绝不允许为 null。
• 请求 ID不得在同一会话内被请求方重复使用。

示例：

{
  jsonrpc: "2.0";
  id: string | number;
  method: string;
  params?: {
    [key: string]: unknown;
  };
}

响应用于回复请求，包含操作的执行结果或错误信息，分为成功响应、错误响应。

成功响应有以下要求：

• 成功响应必须携带对应请求的相同 ID。
• 成功响应必须包含 result 字段。
• result 字段可采用任意 JSON 对象结构。

成功响应示例：

{
  jsonrpc: "2.0";
  id: string | number;
  result: {
    [key: string]: unknown;
  }
}

错误响应有以下要求：

• 错误响应必须携带对应请求的相同 ID（因请求格式非法无法读取 ID 的错误场景除外）。
• 错误响应必须包含携带 code（错误码）和 message（错误信息）的 error 字段。
• 错误码必须为整型。

错误响应示例：

{
  jsonrpc: "2.0";
  id?: string | number;
  error: {
    code: number;
    message: string;
    data?: unknown;
  }
}

通知是客户端与服务器之间互发的单向消息。接收方绝不允许回复响应。

通知消息示例：

{
  jsonrpc: "2.0";
  method: string;
  params?: {
    [key: string]: unknown;
  };
}

3.2 生命周期管理

原生 SON-RPC 是无状态的，而 MCP 在其之上构建了有状态长连接会话，这是 MCP 最关键的设计之一。MCP 为客户端–服务器连接定义了严格的生命周期，以确保正确完成能力协商与状态管理。

定义了严格的三阶段生命周期

• 初始化：能力协商与协议版本达成一致
• 运行：正常协议通信
• 关闭：优雅终止连接

整体流程如下：

3.3 授权

MCP 在传输层提供授权能力，使 MCP 客户端能够代表资源所有者向受限制的 MCP 服务器发起请求。

授权机制基于以下成熟规范实现，并精选子集功能，在保证安全与互操作性的同时保持简洁：

• OAuth 2.0
• OAuth 2.1
• OpenID Connect 1.0

3.4 其他能力

3.4.1 心跳检测

心跳检测功能通过简单的请求/响应模式实现。客户端或服务器均可发送 ping 请求来发起心跳检测。

心跳请求是无参数的标准 JSON-RPC 请求：

{
  "jsonrpc": "2.0",
  "id": "123",
  "method": "ping"
}

接收方必须立即返回空响应：

{
  "jsonrpc": "2.0",
  "id": "123",
  "result": {}
}

若在合理超时时间内未收到响应，发送方可以：

• 认为连接已失效
• 终止连接
• 执行重连流程

3.4.2 取消机制

支持通过通知消息对正在处理的请求进行取消，通信双方均可发送取消通知，告知对方终止此前已发出的请求。

3.4.3 进度跟踪

支持通过通知消息对长时间运行的操作进行可选进度跟踪，通信双方均可发送进度通知，实时更新操作状态。

3.4.4 任务

允许请求方（根据通信方向，可为客户端或服务器）使用任务对请求进行增强。

任务将参与方分为「请求方」与「接收方」，定义如下：

• 请求方（Requestor）：发送任务增强型请求的一方，可为客户端或服务器，任意一方均可创建任务。
• 接收方（Receiver）：接收任务增强型请求、并执行任务的一方，可为客户端或服务器，任意一方均可接收并执行任务。