Architecture
MCP 采用客户端 – 服务器架构，其中 MCP 主机（eg. Claude Code 或 Claude Desktop app）会与一个或多个 MCP 服务器建立连接。MCP 主机通过为每个 MCP 服务器创建一个 MCP 客户端来实现这一过程。每个 MCP 客户端均与其对应的 MCP 服务器保持专属连接。
采用标准输入输出（STDIO）传输方式的本地 MCP 服务器，通常仅为单个 MCP 客户端提供服务；而采用流式 HTTP 传输方式的远程 MCP 服务器，一般可同时为多个 MCP 客户端提供服务。
MCP 架构中的核心参与主体包括：
MCP 主机：负责协调并管理一个或多个 MCP 客户端的 AI app
MCP 客户端：用于维持与 MCP 服务器的连接，并从 MCP 服务器获取context 供 MCP 主机使用的组件
MCP 服务器：为 MCP 客户端提供context的程序
MCP 包含两个Layer：
Data Layer：定义基于 JSON-RPC 的客户端 – 服务器通信协议，涵盖生命周期管理，以及工具、资源、提示词和通知等Primitives。
Transform Layer：定义实现客户端与服务器间数据交换的通信机制与通道，包括特定于Transform Layer的连接建立、消息帧封装与授权验证。
从概念上讲，Data Layer为内层，Transform Layer为外层。
Data Layer
Data Layer实现了一种基于 JSON-RPC 2.0 的交互协议，该协议定义了消息结构与语义。此层包含以下内容：
生命周期管理：处理客户端与服务器之间的连接初始化、能力协商以及连接终止
server功能：支持服务器提供核心功能，包括用于 AI 操作的工具、上下文数据资源，以及面向客户端或接收自客户端的交互模板提示词
client功能：支持服务器请求客户端从宿主大模型中进行采样、获取用户输入，并向客户端发送日志消息
实用功能：支持其他附加能力，例如实时更新通知以及对耗时较长操作的进度跟踪
Transform Layer
Transform Layer负责管理客户端与服务器之间的通信通道及身份验证。它处理 MCP 参与方之间的连接建立、消息分帧以及安全通信。
MCP 支持两种传输机制：
标准输入输出传输：利用标准输入 / 输出流，实现同一台设备上本地进程间的直接进程通信，无网络开销，性能表现最佳。
可流式传输 HTTP 传输：通过 HTTP POST 方式传输客户端至服务器的消息，并可选用服务器发送事件实现流式传输能力。该传输机制支持远程服务器通信，同时兼容标准 HTTP 身份验证方式，包括承载令牌、API 密钥以及自定义请求头。MCP 建议使用 OAuth 协议获取身份验证令牌。
Transform Layer将通信细节与协议层相隔离，使得所有传输机制均可采用统一的 JSON-RPC 2.0 消息格式。
Data Layer协议
MCP 的核心环节之一，是定义 MCP 客户端与 MCP 服务器之间的数据模式及语义。
MCP 采用 JSON-RPC 2.0 作为底层远程过程调用协议。客户端与服务器相互发送请求并作出相应应答。在无需返回应答的场景下，可使用通知机制。
生命周期管理
MCP 是一种有状态协议，需要进行生命周期管理。生命周期管理的作用，是协商客户端与服务器双方所支持的功能特性。
Primitives
MCP Primitives是 MCP 体系中最为核心的概念，其定义了客户端与服务端之间可相互提供的能力。这些原语明确了可与AI Application共享的上下文信息类型，以及可执行的操作范围。
MCP 定义了服务端可对外提供的三类核心Primitives：
- 工具：AI Application可调用的可执行函数，用于执行各类操作（如文件操作、接口调用、数据库查询）
- 资源：为AI Application提供上下文信息的数据源（如文件内容、数据库记录、接口响应数据）
- 提示词：用于构建与大语言模型交互逻辑的可复用模板（如系统提示词、少样本示例）
每类Primitives均配套有发现（/list）、获取（/get）方法，部分类型还支持执行操作（工具 / 调用）。MCP 客户端将通过 */list 方法查找可用的Primitives。例如，客户端可先列出所有可用工具（tools/list），再执行相应操作。该设计支持动态获取可用列表。
MCP 还定义了客户端可对外提供的Primitives。这些Primitives让 MCP 服务端开发者能够构建更丰富的交互场景:
- 采样：允许服务端从客户端的AI Application中请求语言模型补全结果。当服务端开发者需要调用语言模型，又希望保持模型无关性、不在 MCP 服务端中集成语言模型软件开发工具包时，该功能十分实用。他们可通过采样 / 补全方法，向客户端的AI Application请求语言模型补全内容。
- 信息获取：允许服务端向用户请求补充信息。当服务端开发者需要从用户处获取更多信息，或请求确认某项操作时，该功能可发挥作用。他们可通过信息获取 / 请求方法，向用户征集额外信息。
- 日志记录：支持服务端向客户端发送日志信息，用于调试与监控。
通知
MCP协议支持实时通知，以实现服务器与客户端之间的动态更新。例如，当服务器的可用工具发生变化时 —— 如新功能上线或现有工具被修改 —— 服务器可发送工具更新通知，告知已连接的客户端这些变更。通知以 JSON-RPC 2.0 通知消息的形式发送（无需等待响应），使 MCP 服务器能够向已连接的客户端提供实时更新。
example:
1.初始化（生命周期管理）
MCP 的起始环节是通过能力协商握手实现生命周期管理。如生命周期管理章节所述，客户端会发送初始化请求以建立连接，并协商所支持的功能特性。
InitializeRequest:
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-06-18",
"capabilities": {
"elicitation": {}
},
"clientInfo": {
"name": "example-client",
"version": "1.0.0"
}
}
}InitializeResponse:
JSON
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"protocolVersion": "2025-06-18",
"capabilities": {
"tools": {
"listChanged": true
},
"resources": {}
},
"serverInfo": {
"name": "example-server",
"version": "1.0.0"
}
}
}理解初始化交互流程
初始化流程是 MCP 生命周期管理的关键环节，具备多项核心作用：
协议版本协商：protocolVersion 字段（如 “2025-06-18”）用于确保客户端与服务端采用兼容的协议版本，避免因不同版本交互引发通信异常。若无法协商出双方兼容的版本，则应终止连接。
能力发现：capabilities 对象允许通信双方声明自身支持的功能，包括可处理的基础类型（工具、资源、提示词），以及是否支持通知类功能等。此举可规避不被支持的操作，实现高效通信。
身份信息交换：clientInfo 与 serverInfo 对象提供身份标识及版本信息，便于问题排查与兼容性处理。
客户端能力：
“elicitation”: {} – 客户端声明其能够处理用户交互请求（可接收启发式调用 / 创建方法调用）
服务端能力：
“tools”: {“listChanged”: true} – 服务端支持工具原语，并且在其工具列表发生变更时能够发送 tools/list_changed 通知
“resources”: {} – 服务端同时支持资源原语（可处理 resources/list 和 resources/read 方法）
初始化成功后，客户端会发送一条通知，表明自身已就绪：
{
"jsonrpc": "2.0",
"method": "notifications/initialized"
}这一机制在AI Application中的运作方式
初始化阶段，AI Application的多客户端程序管理器会与已配置的服务器建立连接，并存储其功能信息以供后续使用。应用程序会依据这些信息，判断哪些服务器能够提供特定类型的功能（工具、资源、提示词），以及这些服务器是否支持实时更新。
# 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)工具发现（Primitives）
连接建立完成后，客户端可通过发送 tools/list 请求来发现可用工具。该请求是 MCP 工具发现机制的基础 —— 它使客户端在尝试使用工具之前，能够了解服务器上存在哪些可用工具。
{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/list"
}{
"jsonrpc": "2.0",
"id": 2,
"result": {
"tools": [
{
"name": "calculator_arithmetic",
"title": "Calculator",
"description": "Perform mathematical calculations including basic arithmetic, trigonometric functions, and algebraic operations",
"inputSchema": {
"type": "object",
"properties": {
"expression": {
"type": "string",
"description": "Mathematical expression to evaluate (e.g., '2 + 3 * 4', 'sin(30)', 'sqrt(16)')"
}
},
"required": ["expression"]
}
},
{
"name": "weather_current",
"title": "Weather Information",
"description": "Get current weather information for any location worldwide",
"inputSchema": {
"type": "object",
"properties": {
"location": {
"type": "string",
"description": "City name, address, or coordinates (latitude,longitude)"
},
"units": {
"type": "string",
"enum": ["metric", "imperial", "kelvin"],
"description": "Temperature units to use in response",
"default": "metric"
}
},
"required": ["location"]
}
}
]
}
}响应包含一个工具数组，该数组提供了每个可用工具的完整元数据。这种基于数组的结构允许服务器同时公开多个工具，同时保持不同功能之间的清晰界限。
响应中的每个工具对象都包含几个关键字段：
name：工具在服务器命名空间中的唯一标识符。它是工具执行的主键，应遵循清晰的命名规范（例如，calculator_arithmetic 而非仅 calculate）
title：工具的人类可读显示名称，客户端可向用户展示该名称
description：对工具功能及使用场景的详细说明
properties：定义预期输入参数的 JSON 模式，可用于类型验证，并清晰说明必填和可选参数
该机制在AI Application 中的运作方式
AI Application会从所有已连接的多通道处理服务器中获取可用工具，并将其整合为统一的工具注册表，供语言模型调用。这使得大语言模型能够明确自身可执行的操作，并在对话过程中自动生成对应的工具调用指令。
# 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)工具执行（Primitives）
客户端现在可通过 tools/call 方法执行工具。这展示了 MCP Primitives在实际中的使用方式：在发现可用工具后，客户端可通过合适的参数调用这些工具。
理解工具执行请求
tools/call 请求遵循结构化格式，可保障类型安全，并实现客户端与服务端之间的清晰通信。请注意，此处使用的是来自发现响应中的正式工具名称（weather_current），而非简化名称。
{
"jsonrpc": "2.0",
"id": 3,
"method": "tools/call",
"params": {
"name": "weather_current",
"arguments": {
"location": "San Francisco",
"units": "imperial"
}
}
}{
"jsonrpc": "2.0",
"id": 3,
"result": {
"content": [
{
"type": "text",
"text": "Current weather in San Francisco: 68°F, partly cloudy with light winds from the west at 8 mph. Humidity: 65%"
}
]
}
}工具执行的关键要素
请求结构包含多个重要组成部分：
名称：必须与服务发现响应中的工具名称（weather_current）完全一致。这可确保服务器能够正确识别待执行的工具。
参数：包含工具输入模式中定义的输入参数。
JSON-RPC 结构：采用标准 JSON-RPC 2.0 格式，并配备唯一标识用于请求与响应的关联匹配。
工具执行响应解析
该响应体现了多内容协议（MCP）灵活的内容体系：
内容数组：工具响应会返回一个内容对象数组，支持多格式响应内容（文本、图片、资源文件等）。
内容类型：每个内容对象均包含类型字段。多内容协议（MCP）可支持适用于不同应用场景的多种内容类型。
结构化输出：响应提供可直接使用的信息，可供AI Application作为与语言模型交互时的上下文依据。
这种执行模式使得AI Application 能够动态调用服务器功能，并获取结构化响应，进而将其融入与语言模型的对话流程中。
这一机制在AI Application 中的运作方式
当语言模型在对话过程中决定调用工具时，AI Application会拦截该工具调用请求，将其路由至对应的 MCP 服务器，执行相关操作，并将执行结果作为对话流程的一部分返回给大语言模型。这使得大语言模型能够获取实时数据，并在外部环境中执行相应操作。
# 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)实时更新（通知）
MCP 支持实时通知功能，使服务端能够在无需客户端主动请求的情况下，向其告知各类变更信息。这一通知系统是 MCP 的核心特性之一，能够保障 MCP 连接保持同步且具备实时响应能力。
当服务端的可用工具发生变化时 —— 例如新增功能可用、现有工具被修改，或工具暂时不可用 —— 服务端可主动向已连接的客户端发送通知：
{
"jsonrpc": "2.0",
"method": "notifications/tools/list_changed"
}MCP 通知的核心特性
无需响应：请注意通知中不存在 id 字段。这遵循 JSON-RPC 2.0 通知规范，即无需期待也不会发送任何响应。
基于能力：该通知仅由在初始化阶段于工具能力项中声明 “listChanged”: true 的服务端发送。
事件驱动：服务端根据内部状态变化自主决定发送通知的时机，使 MCP 连接具备动态性与响应性。
客户端对通知的处理
客户端接收到该通知后，通常会主动请求获取更新后的工具列表。由此形成刷新循环，确保客户端对可用工具的认知保持最新状态。
{
"jsonrpc": "2.0",
"id": 4,
"method": "tools/list"
}这种通知模式不仅适用于工具，还可拓展至其他模型MCP基础组件，实现客户端与服务器之间全面的实时同步。
该机制在AI Application 中的运作方式
当AI Application 接收到工具变更的通知时，会立即刷新工具注册表，并更新大语言模型的可用功能。这可确保正在进行的对话始终能够调用最新的工具集合，同时大语言模型能够在新功能上线时动态适配。
# 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()MCP Servers
MCP 服务器是通过标准化协议接口向AI Application 开放特定功能的程序。
常见的示例包括用于文档访问的文件系统服务器、用于数据查询的数据库服务器、用于代码管理的 GitHub 服务器、用于团队沟通的 Slack 服务器以及用于日程安排的日历服务器etc
Tools:
工具能够让AI模型执行各类操作。每个工具都定义了一项带有类型化输入与输出的特定操作。模型会根据上下文请求执行工具。
工具的工作原理
工具是LLM可以调用的、基于模式定义的接口。模型上下文协议采用 JSON 模式进行验证。每个工具仅执行一项操作，且具备明确定义的输入与输出。工具在执行前可能需要获得用户授权，从而确保用户能够掌控模型所执行的操作。
Protocol operations:
- tools/list
- tools/call
工具由模型自主管控，这意味着LLM能够自主发现并调用工具。不过，模型控制平台（MCP）通过多种机制强调人工监督。
为保障可信性与安全性，应用程序可通过多种方式实现用户管控，例如：
在用户界面中展示可用工具，支持用户设定某一工具是否可在特定交互场景中启用
针对单次工具执行操作弹出确认对话框
通过权限设置预先批准部分安全操作
生成活动日志，记录所有工具执行情况及其执行结果
Resources:
资源为信息提供结构化访问途径,AI Application 可检索这些信息并将其作为上下文提供给各类模型。
资源的工作原理
资源提供来自文件、应用程序接口（APIs）、数据库或LLM理解上下文所需的其他任何来源的数据。应用程序可直接访问该信息并决定如何使用它 —— 无论是选取相关部分、通过嵌入向量进行搜索，还是将全部信息传递给模型。
每个资源都有唯一的统一资源标识符（URI）（例如：file:///path/to/document.md），并会声明其多用途互联网邮件扩展类型（MIME 类型），以实现合适的内容处理。
资源支持两种发现模式：
直接资源：指向特定数据的固定统一资源标识符（URI）。示例：calendar://events/2024 – 返回 2024 年的日历可用时段
资源模板：带有参数的动态统一资源标识符（URI），用于灵活查询。示例：
travel://activities/{city}/{category} – 按城市和类别返回相关活动
travel://activities/barcelona/museums – 返回巴塞罗那的所有博物馆
资源模板包含标题、描述和预期的多用途互联网邮件扩展类型（MIME 类型）等元数据，这使得它们可被发现且具备自文档化特性。
Protocol operations:
- resources/list List available direct resources Array of resource descriptors
- resources/templates/list Discover resource templates Array of resource template definitions
- resources/read Retrieve resource contents Resource data with metadata
- resources/subscribe Monitor resource changes Subscription confirmation
资源由应用程序驱动，这使得应用在获取、处理和呈现可用上下文信息时具备灵活性。常见的交互模式包括：
采用树形或列表视图，以类似文件夹的熟悉结构浏览资源
提供搜索与筛选界面，用于查找特定资源
基于启发式规则或人工智能筛选，自动纳入上下文或提供智能推荐
支持手动或批量选择界面，可添加单个或多个资源
应用程序可根据自身需求，通过任意界面模式实现资源检索功能。该协议不强制要求特定的用户界面模式，因此支持具备预览功能的资源选择器、基于当前对话上下文的智能推荐、可添加多个资源的批量选择功能，以及与现有文件浏览器和数据资源管理器的集成。
Prompts:
提示词提供可复用的模板。它们使 MCP 服务器开发者能够为特定领域提供参数化提示词，或展示如何最优地使用该 MCP 服务器。
提示词的工作原理
提示词是结构化模板，用于定义预期输入内容与交互模式。提示词由用户自主掌控，需要显式调用，而非自动触发。提示词可具备上下文感知能力，能够调用现有资源与工具，构建完整的工作流程。与资源类似，提示词支持参数补全功能，帮助用户查找有效的参数值。
Protocol operations:
- prompts/list Discover available prompts Array of prompt descriptors
- prompts/get Retrieve prompt details Full prompt definition with arguments
提示词由用户控制，需要显式调用。该协议为实现者提供了设计界面的自由，使其在应用中呈现自然的交互体验。核心原则包括：
便捷发现可用提示词
清晰说明每个提示词的功能
带校验的自然参数输入
清晰展示提示词的底层模板
应用通常通过多种用户界面形式呈现提示词，例如：
斜杠命令（输入 “/” 查看可用提示词，如 /plan-vacation）
支持搜索的命令面板
常用提示词的专属界面按钮
提供相关提示词建议的上下文菜单
client
MCP 客户端由宿主应用程序实例化，用于与特定的 MCP 服务器进行通信。宿主应用程序（如 Claude.ai 或集成开发环境）负责管理整体用户体验，并协调多个客户端。每个客户端负责与一台服务器建立单次直接通信。
理解二者的区别至关重要：宿主是用户直接交互的应用程序，而客户端则是实现服务器连接的协议层组件。
除了利用服务器提供的上下文信息外，客户端还可以向服务器提供若干功能特性。这些客户端特性能够让服务器开发者构建更丰富的交互体验
Elicitation
需求引导使服务端能够在交互过程中向用户请求特定信息，从而打造出更具动态性和高响应性的工作流程,为服务器提供了一种按需收集必要信息的结构化方式。服务器无需预先要求提供所有信息，也不会在数据缺失时直接运行失败，而是可以暂停操作，向用户请求特定的输入内容。这能够构建更灵活的交互模式，使服务器根据用户需求进行适配，而非遵循僵化固定的流程。
{
method: "elicitation/requestInput",
params: {
message: "Please confirm your Barcelona vacation booking details:",
schema: {
type: "object",
properties: {
confirmBooking: {
type: "boolean",
description: "Confirm the booking (Flights + Hotel = $3,000)"
},
seatPreference: {
type: "string",
enum: ["window", "aisle", "no preference"],
description: "Preferred seat type for flights"
},
roomType: {
type: "string",
enum: ["sea view", "city view", "garden view"],
description: "Preferred room type at hotel"
},
travelInsurance: {
type: "boolean",
default: false,
description: "Add travel insurance ($150)"
}
},
required: ["confirmBooking"]
}
}
}信息获取交互的设计力求清晰、贴合场景，并充分尊重用户自主权：
请求呈现：客户端展示信息获取请求时，会明确说明发起请求的服务器、所需信息的原因及使用方式。请求消息会阐明用途，而数据规范则提供结构与校验依据。
响应选项：用户可通过合适的界面控件（文本框、下拉菜单、复选框）提供所需信息，也可选择拒绝提供并附上可选说明，或取消整个操作。客户端会依据既定数据规范校验响应内容，再返回至服务器。
隐私考量：信息获取过程绝不索要密码或 API 密钥。客户端会对可疑请求发出警示，并允许用户在发送前核对数据。
Roots
根目录为服务器操作定义了文件系统边界，允许客户端指定服务器需要关注的目录
根路径是客户端向服务端传递文件系统访问边界的一种机制。它由文件统一资源标识符（URI）组成，用于指明服务端可进行操作的目录，帮助服务端明确可访问的文件与文件夹范围。
尽管根路径能够传递预设的访问边界，却无法强制实施安全限制。实际的安全保障必须在操作系统层面，通过文件权限设置和 / 或沙箱机制来强制执行。
{
"uri": "file:///Users/agent/travel-planning",
"name": "Travel Planning Workspace"
}根目录专指文件系统路径，且始终采用 file:// 统一资源标识符格式。它们有助于服务器识别项目边界、工作区结构以及可访问的目录。当用户处理不同项目或文件夹时，根目录列表可动态更新，一旦边界发生变化，服务器会通过 roots/list_changed 接收通知。
根目录通常由宿主应用程序根据用户操作自动管理，不过部分应用程序可能支持手动管理根目录：
自动根目录检测：用户打开文件夹时，客户端会自动将其设为根目录。
手动根目录配置：高级用户可通过配置指定根目录。例如，添加 /travel-templates 目录用于存放可复用资源。
Sampling
采样机制使服务器能够通过客户端请求语言模型生成补全内容，在保障安全性与用户控制权的同时，实现智能体行为。
采样机制使服务器能够执行依赖LLM的任务，而无需直接接入LLM或为其付费。相反，服务器可请求已具备LLM访问权限的客户端代为处理这些任务。该方式让客户端完全掌控用户权限与安全措施。由于采样请求是在其他操作（如工具进行数据分析）的场景中发起，并作为独立的模型调用进行处理，因此能在不同场景间保持清晰界限，从而更高效地利用上下文窗口。
{
messages: [
{
role: "user",
content: "Analyze these flight options and recommend the best choice:\n" +
"[47 flights with prices, times, airlines, and layovers]\n" +
"User preferences: morning departure, max 1 layover"
}
],
modelPreferences: {
hints: [{
name: "claude-sonnet-4-20250514" // Suggested model
}],
costPriority: 0.3, // Less concerned about API cost
speedPriority: 0.2, // Can wait for thorough analysis
intelligencePriority: 0.9 // Need complex trade-off evaluation
},
systemPrompt: "You are a travel expert helping users find the best flights based on their preferences",
maxTokens: 1500
}假设有一个旅游预订服务端，其中包含一个名为 findBestFlight 的工具，该工具通过抽样分析可预订航班并推荐最优选择。当用户提出 “为我预订下个月飞往巴塞罗那的最佳航班” 这一请求时，该工具需要LLM辅助来评估复杂的取舍因素。
该工具会查询航空公司应用程序接口，收集到 47 个航班选项，随后请求LLM对这些选项进行分析：“分析以下航班选项并推荐最佳选择：[包含价格、起降时间、航空公司及中转信息的 47 个航班] 用户偏好：上午出发，中转次数最多 1 次。”
客户端发起抽样请求，使LLM能够权衡各类因素 —— 例如价格更低的航班与出行便捷的航班之间的取舍。该工具依据这份分析结果，为用户呈现排名前三的推荐方案。
采样功能虽非强制要求，但其设计初衷是支持人机协同管控。用户可通过多种机制实施监督：
审批管控：采样请求可能需要用户明确授权。客户端可展示服务器拟分析的内容及原因，用户可对请求进行批准、拒绝或修改操作。
透明化功能：客户端可展示完整的提示词、选用的模型及token限制，使用户能够在 AI 响应返回服务器前完成审核。
配置选项：用户可设定模型偏好，为可信操作配置自动审批，或对所有操作均要求审批。客户端可提供敏感信息脱敏选项。
安全考量：客户端与服务器在采样过程中均需妥善处理敏感数据。客户端应实施请求频率限制，并对所有消息内容进行校验。人机协同设计可确保，未经用户明确许可，服务器发起的 AI 交互不会危及系统安全或获取敏感数据。
评论（1）