本 Model Context Protocol (MCP) 概述讨论了其 范围 和 核心概念，并提供了一个 示例 演示每个核心概念。 因为 MCP SDKs 抽象了许多关注点，大多数开发者可能会发现数据层协议部分是最有用的。它讨论了 MCP 服务器如何为 AI 应用程序提供上下文。 有关具体实现细节，请参阅您的 特定语言 SDK 文档。

​
范围

Model Context Protocol 包括以下项目：
MCP专注于上下文交换的协议——它不规定AI应用程序如何使用LLM或管理所提供的上下文。

​
MCP 的概念

​
参与者

MCP遵循客户端-服务器架构，其中MCP主机——如Claude Code或Claude Desktop这类AI应用程序——与一个或多个MCP服务器建立连接。MCP主机通过为每个MCP服务器创建一个MCP客户端来实现这一点。每个MCP客户端与其对应的MCP服务器保持专用的一对一连接。 MCP架构中的关键参与者包括：
  • MCP Host: 协调和管理一个或多个MCP客户端的AI应用
  • MCP Client：一个组件，用于维护与MCP服务器的连接，并从MCP服务器获取上下文供MCP主机使用
  • MCP Server: 向MCP客户端提供上下文的程序
例如: Visual Studio Code 作为 MCP 主机运行。当 Visual Studio Code 与 MCP 服务器（例如 Sentry MCP server）建立连接时，Visual Studio Code 运行时会实例化一个 MCP 客户端对象，该对象维持与 Sentry MCP 服务器的连接。 当 Visual Studio Code 随后连接到另一个 MCP 服务器（例如 local filesystem server）时，Visual Studio Code 运行时会实例化另一个 MCP 客户端对象来维持此连接，从而保持 MCP 客户端与 MCP 服务器之间的一对一关系。 请注意MCP服务器指的是提供上下文数据的程序，无论其运行位置如何。MCP服务器可以在本地或远程执行。例如，当 Claude Desktop启动文件系统 服务器时， 该服务器在同一台机器上本地运行，因为它使用STDIO 传输方式。这通常被称为"本地"MCP服务器。官方的 Sentry MCP server运行在 Sentry平台上，并使用可流式HTTP传输方式。这通常 被称为"远程"MCP服务器。

​
层级

MCP包括两个层级：
  • 数据层：定义了基于JSON-RPC的客户端-服务器通信协议，包含生命周期管理及核心原语，例如工具、资源、提示和通知。
  • 传输层：定义了客户端与服务器之间实现数据交换的通信机制和通道，包括传输特定的连接建立、消息帧化及授权功能。
从概念上讲，数据层是内层，而传输层是外层。

​
数据层

数据层实现了一个基于JSON-RPC 2.0的交换协议，它定义了消息的结构和语义。 这一层包含：
  • 生命周期管理: 处理客户端与服务器之间的连接初始化、能力协商和连接终止
  • 服务器功能: 使服务器能够提供核心功能，包括用于AI操作的工具、用于上下文数据的资源，以及来自客户端及面向客户端的交互模板提示
  • 客户端功能: 使服务器能够请求客户端从宿主大语言模型进行采样，向用户获取输入，并将消息记录至客户端
  • 实用功能: 支持额外能力，例如实时更新的通知和长时间运行操作的进度追踪

​
传输层

传输层管理客户端与服务器之间的通信通道和认证。它处理MCP参与者之间的连接建立、消息帧化和安全通信。 MCP支持两种传输机制：
  • 标准输入输出传输: 使用标准输入/输出流在同一台机器上的本地进程之间进行直接进程通信，提供最佳性能且无网络开销。
  • 可流式传输的HTTP通信: 使用HTTP POST进行客户端到服务器的消息传输，并可选支持服务器发送事件以实现流式传输能力。这种通信方式支持远程服务器连接，并兼容标准的HTTP认证方法，包括承载令牌、API密钥和自定义标头。MCP建议使用OAuth获取认证令牌。
传输层将通信细节与协议层进行抽象，使得相同的JSON-RPC 2.0消息格式能够适用于所有传输机制。

​
数据层协议

MCP的一个核心部分是定义MCP客户端与MCP服务器之间的架构和语义。开发者很可能会发现数据层——特别是primitives集合——是MCP最有趣的部分。这部分MCP定义了开发者可以将上下文从MCP服务器共享到MCP客户端的方式。 MCP使用 JSON-RPC 2.0 作为其底层RPC协议。客户端和服务器相互发送请求并相应回应。当不需要响应时可以使用通知。

​
生命周期管理

MCP是一个，需要生命周期管理。生命周期管理的目的是协商客户端和服务器都支持的。详细信息可以在specification中找到，而example展示了初始化序列。

​
基元组件

MCP 原语是 MCP 中最重要的概念。它们定义了客户端和服务器可以相互提供的内容。这些原语明确了可共享给 AI 应用程序的上下文信息类型以及可执行的操作范围。 MCP定义了三种核心原语，服务器可将其暴露出来:
  • 工具: 人工智能应用程序可调用的可执行函数，用于执行操作（例如：文件操作、API调用、数据库查询）
  • 资源: 为AI应用提供上下文信息的数据源（例如：文件内容、数据库记录、API响应）
  • 提示词: 可重用模板，帮助构建与语言模型的交互（例如系统提示、少量示例）
每种原始类型都有关联的发现方法（*/list）、检索方法（*/get），有些情况下还包含执行方法（tools/call）。 MCP 客户端将使用 */list 方法来发现可用的原始类型。例如，客户端可以首先列出所有可用工具（tools/list），然后执行它们。该设计允许列表是动态生成的。 作为一个具体示例，考虑一个提供数据库上下文的 MCP 服务器。它可以暴露用于查询数据库的工具、包含数据库模式的资源，以及一个包含与工具交互的少样本示例的提示。 有关服务器原语的更多详细信息，请参阅 服务器概念。 MCP还定义了可以被用户公开的基础元素。这些基础元素允许MCP服务器作者构建更丰富的交互。
  • 采样功能：允许服务器向客户端的AI应用程序请求语言模型补全。当服务器开发者希望使用语言模型但保持模型独立性，且不在其MCP服务器中包含语言模型SDK时，此功能非常有用。他们可以使用sampling/complete方法向客户端的AI应用程序请求语言模型补全。
  • 征求: 允许服务器向用户请求额外信息。当服务器开发者希望从用户处获取更多信息，或要求确认某项操作时，此功能非常有用。他们可以使用elicitation/request方法向用户请求额外信息。
  • 日志记录: 使服务器能够将日志消息发送给客户端，用于调试和监控目的。
关于客户端原语的更多详情，请参阅客户端概念。

​
通知

该协议支持实时通知，以实现服务器与客户端之间的动态更新。例如，当服务器的可用工具发生变化时——比如新功能可用或现有工具被修改——服务器可以发送工具更新通知，告知连接的客户端这些变更。通知以JSON-RPC 2.0通知消息形式发送（不期望响应），使MCP服务器能够向连接的客户端提供实时更新。

​
示例

​
数据层

本部分逐步演示了MCP客户端-服务器交互过程，重点介绍了数据层协议。我们将使用JSON-RPC 2.0消息来展示生命周期序列、工具操作和通知机制。
1

初始化（生命周期管理）

MCP从通过功能协商握手的生命周期管理开始。如生命周期管理部分所述，客户端发送initialize请求以建立连接并协商支持的功能。
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "elicitation": {}
    },
    "clientInfo": {
      "name": "example-client",
      "version": "1.0.0"
    }
  }
}

​
理解初始化交换

初始化过程是MCP生命周期管理的关键部分，且具备若干重要用途：
  1. 协议版本协商: protocolVersion 字段（例如 "2025-06-18"）确保客户端和服务端使用兼容的协议版本。这能够防止不同版本尝试交互时可能出现的通信错误。如果无法协商出双方兼容的版本，则应终止连接。
  2. 能力发现: capabilities 对象允许各方声明它们支持的功能，包括它们能够处理的哪些primitives（工具，资源，提示）以及是否支持像notifications这样的功能。这通过避免执行不支持的操作从而实现了高效的通信。
  3. 身份信息交换: clientInfo 和 serverInfo 对象提供用于调试和兼容性目的的身份标识和版本信息。
在这个示例中，能力协商展示了如何声明 MCP 基本组件：客户端能力:
  • "elicitation": {} - 客户端声明能够处理用户交互请求（可以接收elicitation/create方法调用）
服务器功能:
  • "tools": {"listChanged": true} - 服务器支持工具原语，并且当其工具列表发生变化时能够发送tools/list_changed通知
  • "resources": {} - 服务器还支持资源原语（可以处理 resources/list 和 resources/read 方法）
成功初始化之后，客户端发送通知表示它已就绪：
通知
{
  "jsonrpc": "2.0",
  "method": "notifications/initialized"
}

​
AI应用中的实现原理

在初始化期间，AI应用程序的MCP客户端管理器会与配置好的服务器建立连接，并存储它们的能力以供后续使用。应用程序利用这些信息确定哪些服务器可以提供特定类型的功能（工具、资源、提示），以及是否支持实时更新。
AI 应用初始化的伪代码
# Pseudo Code
async with stdio_client(server_config) as (read, write):
    async with ClientSession(read, write) as session:
        init_response = await session.initialize()
        if init_response.capabilities.tools:
            app.register_mcp_server(session, supports_tools=True)
        app.set_server_ready(session)
2

工具发现（原始能力）

现在已经建立了连接，客户端可以通过发送一个 tools/list 请求来发现可用工具。此请求是 MCP 工具发现机制的基础 —— 它使客户端能够在尝试使用这些工具之前了解服务器上有哪些工具可用。
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/list"
}

​
理解工具发现请求

tools/list 请求很简单，不含参数。

​
理解工具发现响应

响应包含一个tools数组，该数组提供关于每个可用工具的全面元数据。这种基于数组的结构允许服务器同时暴露多个工具，同时保持不同功能之间的清晰边界。响应中的每个工具对象包含若干关键字段：
  • name: 一个在服务命名空间中唯一标识工具的标识符。它作为工具执行的主键，应遵循清晰的命名模式（如：calculator_arithmetic 而不是简单的 calculate）
  • title: 可向用户展示的工具可读显示名称
  • description: 详细说明工具的功能以及何时使用它
  • inputSchema: 一个JSON模式，用于定义预期的输入参数，实现类型验证并提供关于必需和可选参数的清晰文档

​
人工智能应用中的运作原理

人工智能应用从所有连接的 MCP 服务器中获取可用工具，并将它们合并成一个统一的工具注册表，供语言模型访问。这使得大语言模型能够理解它可以执行哪些操作，并在对话过程中自动生成相应的工具调用。
AI应用工具发现的伪代码
# Pseudo-code using MCP Python SDK patterns
available_tools = []
for session in app.mcp_server_sessions():
    tools_response = await session.list_tools()
    available_tools.extend(tools_response.tools)
conversation.register_available_tools(available_tools)
3

工具执行（基础操作）

客户端现在可以使用tools/call方法执行工具。这展示了MCP原语如何在实践中使用：在发现可用工具之后，客户端可以使用适当的参数调用它们。

​
理解工具执行请求

这种tools/call请求遵循结构化格式，确保客户端和服务器之间的类型安全和清晰通信。请注意，我们使用的正确工具名称来自发现响应（weather_current），而非简化名称：
{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "weather_current",
    "arguments": {
      "location": "San Francisco",
      "units": "imperial"
    }
  }
}

​
工具执行的关键要素

请求结构包含几个重要组成部分：
  1. name: 必须严格匹配来自发现响应的工具名称（weather_current）。这确保服务器能够正确识别要执行的工具。
  2. arguments: 包含该工具inputSchema所定义的输入参数。在本示例中：
    • location: “San Francisco” (必需参数)
    • units: “imperial” (可选参数，未指定时默认使用“metric”)
  3. JSON-RPC结构: 使用标准 JSON-RPC 2.0 格式，含有独特的 id 用于请求-响应关联。

​
理解工具执行响应

该响应展示了 MCP 灵活的内容系统：
  1. content 数组: 工具响应返回一个内容对象数组，支持丰富的多格式响应（文本、图像、资源等）
  2. 内容类型: 每个内容对象都有一个type字段。在此示例中，"type": "text"表示纯文本内容，但MCP支持多种内容类型以适用于不同用例场景。
  3. 结构化输出: 响应提供可操作信息，AI应用程序可将其作为语言模型交互的上下文使用。
这种执行模式允许人工智能应用动态调用服务器功能并接收可集成到与语言模型对话的结构化响应。

​
在AI应用中的工作原理

当语言模型在对话过程中决定使用工具时，AI应用程序会拦截工具调用，将其路由到适当的MCP服务器，执行该调用，并将结果作为对话流程的一部分返回给LLM。这使得LLM能够访问实时数据并在外部世界中执行操作。
# Pseudo-code for AI application tool execution
async def handle_tool_call(conversation, tool_name, arguments):
    session = app.find_mcp_session_for_tool(tool_name)
    result = await session.call_tool(tool_name, arguments)
    conversation.add_tool_result(result.content)
4

实时更新（通知）

MCP支持实时通知功能，使得服务器能够在无需显式请求的情况下向客户端告知变更。这展示了通知系统，它是保持MCP连接同步与响应能力的关键特性。

​
理解工具列表变更通知

当服务器可用工具发生变化时——例如新功能上线、现有工具修改或工具临时不可用——服务器可以主动通知已连接的客户端:
请求
{
  "jsonrpc": "2.0",
  "method": "notifications/tools/list_changed"
}

​
MCP通知的主要特性

  1. 无需响应: 注意通知中不存在id字段。这遵循了JSON-RPC 2.0通知语义，其中既不期望也不发送任何响应。
  2. 基于能力: 此通知仅由在初始化期间在其工具能力中声明了 "listChanged": true 的服务器发送（如步骤1所示）。
  3. 事件驱动: 服务器基于内部状态变化决定何时发送通知, 使MCP连接动态且响应迅速。

​
客户端对通知的响应

接收到此通知后，客户端通常通过请求更新的工具列表作出反应。这形成一个刷新周期，使客户端对可用工具的理解保持最新：
请求
{
  "jsonrpc": "2.0",
  "id": 4,
  "method": "tools/list"
}

​
为什么通知很重要

该通知系统至关重要，原因如下：
  1. 动态环境: 工具可能根据服务器状态、外部依赖或用户权限动态出现或消失
  2. 效率: 客户端无需轮询变更；当更新发生时它们会收到通知
  3. 一致性: 确保客户端始终准确了解可用的服务器功能
  4. 实时协作: 赋能响应式AI应用，可适应不断变化的上下文环境
这一通知模式不仅适用于工具，还延伸至其他MCP基本元素，实现客户端与服务器之间全面的实时同步。

​
AI 应用中的工作原理

当AI应用接收到关于工具变更的通知时，它会立即刷新工具注册表并更新LLM的可用能力。这确保进行中的对话始终能访问最新的工具集，并且LLM可以动态适配新功能。
# Pseudo-code for AI application notification handling
async def handle_tools_changed_notification(session):
    tools_response = await session.list_tools()
    app.update_available_tools(session, tools_response.tools)
    if app.conversation.is_active():
        app.conversation.notify_llm_of_new_capabilities()