摘要MCP协议采用Host-Client-Server三层架构Host管理客户端实例Client负责协议通信Server提供工具和资源。本文深入解析架构组件职责、通信流程和设计原理。MCP协议全景Host Client Server架构详解我花了不少时间才把MCP的架构彻底搞明白。一开始我以为就是客户端连服务端那么简单后来发现协议里分了Host、Client、Server三个角色加上传输层和生命周期管理整个体系比想象中复杂。这篇文章我把MCP的三层架构、组件职责、通信流程和生命周期管理从头到尾梳理一遍配上ASCII图和表格帮你建立完整的架构认知。三层架构总览MCP的架构分为三个角色Host、Client和Server。它们的关系如下。---------------------------------------------------------- | Host (宿主应用) | | | | ------------ ------------ ------------ | | | Client A | | Client B | | Client C | | | ----------- ----------- ----------- | | | | | | ---------|------------------|------------------|---------- | stdio | stdio | HTTP | | | ------------ ------------ ------------ | Server A | | Server B | | Server C | | (文件系统) | | (数据库) | | (Web API) | ------------- ------------- -------------Host是宿主应用比如Claude Desktop、Cursor IDE或者你自己写的AI应用。Host负责管理用户界面、处理LLM对话同时管理多个Client实例。Client是Host内部的连接器每个Client跟一个Server建立一对一的连接。Host想连3个Server就创建3个Client实例。Client负责协议握手、能力协商、消息收发它是Host和Server之间的桥梁。Server是能力提供方暴露Tools、Resources、Prompts三种能力供Client调用。Server可以是本地子进程stdio传输也可以是远程HTTP服务Streamable HTTP传输。各组件职责详解Host的职责Host是整个架构的入口和管理者。它做这几件事。管理Client实例的创建和销毁。用户在配置里加了一个新ServerHost就创建一个新Client去连接。用户删了配置Host就关闭对应的Client和Server连接。控制权限和审批。LLM想调用某个工具时Host负责弹出确认对话框让用户批准。这是MCP安全模型的核心工具调用默认需要用户确认Host是守门人。聚合多个Server的能力。Host把所有连接的Server的工具列表合并起来统一呈现给LLM。LLM看到的是一组工具不用关心背后连了几个Server。处理LLM交互。Host管理跟大语言模型的对话把Server提供的上下文工具结果、资源内容、prompt模板喂给LLM再把LLM的响应展示给用户。Client的职责Client是协议层面的执行者。每个Client实例对应一个Server连接。发起initialize握手。Client主动向Server发送initialize请求协商协议版本和能力握手完成后发送initialized通知。维护连接状态。Client跟踪当前处于生命周期的哪个阶段初始化中、正常操作中还是关闭中。转发消息。Host要调用某个Server的工具时通过对应的Client发JSON-RPC请求收到响应后转发给Host。处理Server发起的请求。Server也可以向Client发请求比如sampling请求Client用LLM生成文本和elicitation请求Client向用户提问。Client收到这些请求后交给Host处理。Server的职责Server是能力提供方专注于暴露数据和功能。注册Tools、Resources、Prompts。Server在启动时声明自己提供哪些能力等Client来查询和调用。执行工具逻辑。Client调用tools/call时Server执行对应的工具函数返回结果。管理资源。Server维护资源列表Client可以读取资源内容、订阅资源变更。提供prompt模板。Server预定义prompt模板Client传入参数后获取生成的消息。发送通知。Server可以主动发送通知比如工具列表变更tools/list_changed、资源更新resources/updated、日志消息notifications/message。通信流程我画一个完整的通信流程从建立连接到调用工具再到断开连接。Client Server | | | 阶段1 初始化握手 | | | | --- initialize request --- | | method: initialize | | protocolVersion: 2025-06-18 | | capabilities: { roots, sampling } | | clientInfo: { name, version } | | | | --- initialize response --- | | protocolVersion: 2025-06-18 | | capabilities: { tools, resources, | | prompts, logging } | | serverInfo: { name, version } | | | | --- initialized notification --- | | method: notifications/initialized | | | | 阶2 正常操作 | | | | --- tools/list request --- | | --- tools/list response --- | | 返回工具列表和schema | | | | --- tools/call request --- | | method: tools/call | | params: { name, arguments } | | | | --- tools/call response --- | | result: { content, isError } | | | | 阶段3 关闭 | | | | 关闭stdin / 发SIGTERM | | Server退出这个流程里有几个关键点。握手必须先于一切操作。Client发initialize请求后必须等到Server返回响应才能发initialized通知。收到initialized通知后Server才开始处理业务请求。在握手完成前双方只能发ping请求。消息是双向的。虽然大部分时候是Client发请求Server响应但Server也可以主动发请求。比如Server想用Client的LLM能力做sampling就由Server发请求Client响应。这种双向通信是MCP跟传统RPC的一个重要区别。能力协商握手阶段最重要的环节是能力协商。Client和Server各自声明自己支持的能力只有双方都声明的能力才能在操作阶段使用。能力类别能力名称声明方说明Clientroots客户端提供文件系统根目录给Server访问Clientsampling客户端支持Server请求LLM采样Clientelicitation客户端支持Server向用户提问Clientexperimental客户端实验性非标准功能Serverprompts服务端提供prompt模板Serverresources服务端提供可读资源Servertools服务端提供可调用工具Serverlogging服务端发送结构化日志Servercompletions服务端支持参数自动补全Serverexperimental服务端实验性非标准功能部分能力还有子能力。比如resources可以带subscribe支持订阅和listChanged支持列表变更通知。prompts和tools可以带listChanged。能力协商的规则很简单双方都有的能力才能用。如果Server想发sampling请求但Client没声明sampling能力就会失败。反过来如果Client想订阅资源但Server没声明subscribe子能力也行不通。生命周期管理MCP连接的生命周期分三个阶段初始化、操作和关闭。初始化阶段Client发起initialize请求携带三项信息。protocolVersion是客户端支持的协议版本应该是客户端支持的最新版本。capabilities是客户端能力声明。clientInfo是客户端实现信息包括名称和版本。Server收到后返回自己的protocolVersion、capabilities和serverInfo。如果Server支持Client请求的协议版本返回相同版本。如果不支持返回Server支持的最新版本。Client收到后如果不支持Server返回的版本应该断开连接。协议版本协商完成后Client发送initialized通知握手正式结束。当前最新协议版本是2025-06-18。更早的版本有2025-03-26和2024-11-05。版本间的差异主要在传输层2024-11-05用的是HTTPSSE传输2025-06-18换成了Streamable HTTP。操作阶段握手完成后进入操作阶段双方按协商好的能力和协议版本交换消息。这个阶段双方都要遵守两条规则。第一只使用协商成功的协议版本。第二只使用双方都声明了的能力。Client可以发请求tools/call、resources/read、prompts/get等和通知取消通知、进度通知等。Server可以发响应、通知日志、列表变更、资源更新等和请求sampling、elicitation。关闭阶段关闭阶段没有专门的消息靠传输层机制来终止连接。stdio传输的关闭流程是这样。Client先关闭Server子进程的输入流stdin等待Server自行退出。如果等了合理时间Server还没退出Client发SIGTERM信号。再等一段时间还不退出发SIGKILL强制终止。Streamable HTTP传输的关闭通过关闭HTTP连接实现。Client不再需要某个session时应该发HTTP DELETE请求带上Mcp-Session-Id头显式终止session。Server也可以主动终止session之后对该session的请求返回404。传输层对比MCP目前定义了两种标准传输机制。对比维度stdioStreamable HTTP适用场景本地开发、桌面应用远程服务、云部署连接方式子进程stdin/stdoutHTTP POST/GET消息分隔换行符分隔HTTP body日志输出stderrnotifications/message通知会话管理进程生命周期Mcp-Session-Id头多客户端一对一一对多流式支持不支持SSE流式响应断线重连需重启进程支持resumabilitystdio适合本地场景。Client把Server作为子进程启动通过stdin发消息从stdout读响应。好处是简单直接不用管网络。坏处是一对一每个Client要启动一个Server进程。Streamable HTTP适合远程场景。Server作为独立HTTP服务运行多个Client可以连同一个Server。支持SSE流式传输Server可以主动推送消息。有session管理机制通过Mcp-Session-Id头标识会话。协议规范建议Client尽可能支持stdio因为本地场景下stdio最简单高效。一个实际架构示例我用一个具体场景说明架构怎么用起来。假设你做了一个AI编程助手需要让LLM访问本地文件系统、查询数据库和调用外部API。-------------------------------------------------- | AI编程助手 (Host) | | | | ---------- ---------- ---------- | | | Client 1 | | Client 2 | | Client 3 | | | --------- --------- --------- | -------|---------------|---------------|---------- | stdio | stdio | HTTP | | | ----------- ----------- ----------- | FS Server | | DB Server | | API Server | | 读写本地文件 | | 查询MySQL | | 调用GitHub | ------------ ------------ ------------Host是AI编程助手应用。它创建3个Client分别连接3个Server。文件系统Server用stdio在本地运行数据库Server也用stdio本地运行GitHub API Server用Streamable HTTP部署在远程。LLM在对话中需要读取文件时Host通过Client 1调用FS Server的read_file工具。需要查数据库时通过Client 2调用DB Server的query工具。需要查GitHub仓库信息时通过Client 3调用API Server的工具。Host把三个Server的工具列表合并后统一呈现给LLMLLM不用知道背后有几个Server。常见问题与避坑第一个坑搞混Host和Client的角色。Host是应用层面的管理者Client是协议层面的连接器。一个Host内部可以有多个Client每个Client连一个Server。开发时如果你写的是Host要同时管理多个Client的生命周期。如果你写的是Server只管跟一个Client通信就行。第二个坑协议版本协商失败没处理。Client请求版本AServer返回版本BClient直接按版本A继续通信结果两边行为不一致。正确做法是检查Server返回的版本不兼容就断开。第三个坑stdio模式下Server没有正确退出。Client关闭stdin后Server应该检测到EOF并退出但有些Server代码没处理stdin的end事件进程一直挂着。Client只能靠SIGKILL强制杀掉可能导致资源没释放。Server代码里要监听stdin的end事件做清理。第四个坑HTTP模式下忘了带Mcp-Session-Id头。Streamable HTTP传输在initialize响应里返回session ID后续所有请求都要带这个头。漏了的话Server返回400 Bad Request。用SDK的话会自动处理自己写客户端容易忘。第五个坑能力协商后用了没协商的能力。比如Server代码里调了sampling但Client没声明sampling能力运行时报-32602错误。开发时用Inspector检查initialize握手消息确认双方能力声明符合预期。小结MCP的三层架构里Host管理多个Client每个Client连接一个ServerServer暴露Tools/Resources/Prompts三种能力。通信流程分初始化握手、正常操作和关闭三个阶段握手时做协议版本和能力协商。传输层支持stdio和Streamable HTTP两种方式分别适合本地和远程场景。理解这个架构的关键是搞清三个角色的边界Host管协调Client管协议Server管能力各司其职。相关推荐MCP是什么为什么2026年每个AI开发者都需要了解它JSON-RPC 2.0MCP通信的底层语言传输层详解stdio vs SSE vs Streamable HTTP MCP协议全景：Host、Client、Server架构详解
摘要MCP协议采用Host-Client-Server三层架构Host管理客户端实例Client负责协议通信Server提供工具和资源。本文深入解析架构组件职责、通信流程和设计原理。MCP协议全景Host Client Server架构详解我花了不少时间才把MCP的架构彻底搞明白。一开始我以为就是客户端连服务端那么简单后来发现协议里分了Host、Client、Server三个角色加上传输层和生命周期管理整个体系比想象中复杂。这篇文章我把MCP的三层架构、组件职责、通信流程和生命周期管理从头到尾梳理一遍配上ASCII图和表格帮你建立完整的架构认知。三层架构总览MCP的架构分为三个角色Host、Client和Server。它们的关系如下。---------------------------------------------------------- | Host (宿主应用) | | | | ------------ ------------ ------------ | | | Client A | | Client B | | Client C | | | ----------- ----------- ----------- | | | | | | ---------|------------------|------------------|---------- | stdio | stdio | HTTP | | | ------------ ------------ ------------ | Server A | | Server B | | Server C | | (文件系统) | | (数据库) | | (Web API) | ------------- ------------- -------------Host是宿主应用比如Claude Desktop、Cursor IDE或者你自己写的AI应用。Host负责管理用户界面、处理LLM对话同时管理多个Client实例。Client是Host内部的连接器每个Client跟一个Server建立一对一的连接。Host想连3个Server就创建3个Client实例。Client负责协议握手、能力协商、消息收发它是Host和Server之间的桥梁。Server是能力提供方暴露Tools、Resources、Prompts三种能力供Client调用。Server可以是本地子进程stdio传输也可以是远程HTTP服务Streamable HTTP传输。各组件职责详解Host的职责Host是整个架构的入口和管理者。它做这几件事。管理Client实例的创建和销毁。用户在配置里加了一个新ServerHost就创建一个新Client去连接。用户删了配置Host就关闭对应的Client和Server连接。控制权限和审批。LLM想调用某个工具时Host负责弹出确认对话框让用户批准。这是MCP安全模型的核心工具调用默认需要用户确认Host是守门人。聚合多个Server的能力。Host把所有连接的Server的工具列表合并起来统一呈现给LLM。LLM看到的是一组工具不用关心背后连了几个Server。处理LLM交互。Host管理跟大语言模型的对话把Server提供的上下文工具结果、资源内容、prompt模板喂给LLM再把LLM的响应展示给用户。Client的职责Client是协议层面的执行者。每个Client实例对应一个Server连接。发起initialize握手。Client主动向Server发送initialize请求协商协议版本和能力握手完成后发送initialized通知。维护连接状态。Client跟踪当前处于生命周期的哪个阶段初始化中、正常操作中还是关闭中。转发消息。Host要调用某个Server的工具时通过对应的Client发JSON-RPC请求收到响应后转发给Host。处理Server发起的请求。Server也可以向Client发请求比如sampling请求Client用LLM生成文本和elicitation请求Client向用户提问。Client收到这些请求后交给Host处理。Server的职责Server是能力提供方专注于暴露数据和功能。注册Tools、Resources、Prompts。Server在启动时声明自己提供哪些能力等Client来查询和调用。执行工具逻辑。Client调用tools/call时Server执行对应的工具函数返回结果。管理资源。Server维护资源列表Client可以读取资源内容、订阅资源变更。提供prompt模板。Server预定义prompt模板Client传入参数后获取生成的消息。发送通知。Server可以主动发送通知比如工具列表变更tools/list_changed、资源更新resources/updated、日志消息notifications/message。通信流程我画一个完整的通信流程从建立连接到调用工具再到断开连接。Client Server | | | 阶段1 初始化握手 | | | | --- initialize request --- | | method: initialize | | protocolVersion: 2025-06-18 | | capabilities: { roots, sampling } | | clientInfo: { name, version } | | | | --- initialize response --- | | protocolVersion: 2025-06-18 | | capabilities: { tools, resources, | | prompts, logging } | | serverInfo: { name, version } | | | | --- initialized notification --- | | method: notifications/initialized | | | | 阶2 正常操作 | | | | --- tools/list request --- | | --- tools/list response --- | | 返回工具列表和schema | | | | --- tools/call request --- | | method: tools/call | | params: { name, arguments } | | | | --- tools/call response --- | | result: { content, isError } | | | | 阶段3 关闭 | | | | 关闭stdin / 发SIGTERM | | Server退出这个流程里有几个关键点。握手必须先于一切操作。Client发initialize请求后必须等到Server返回响应才能发initialized通知。收到initialized通知后Server才开始处理业务请求。在握手完成前双方只能发ping请求。消息是双向的。虽然大部分时候是Client发请求Server响应但Server也可以主动发请求。比如Server想用Client的LLM能力做sampling就由Server发请求Client响应。这种双向通信是MCP跟传统RPC的一个重要区别。能力协商握手阶段最重要的环节是能力协商。Client和Server各自声明自己支持的能力只有双方都声明的能力才能在操作阶段使用。能力类别能力名称声明方说明Clientroots客户端提供文件系统根目录给Server访问Clientsampling客户端支持Server请求LLM采样Clientelicitation客户端支持Server向用户提问Clientexperimental客户端实验性非标准功能Serverprompts服务端提供prompt模板Serverresources服务端提供可读资源Servertools服务端提供可调用工具Serverlogging服务端发送结构化日志Servercompletions服务端支持参数自动补全Serverexperimental服务端实验性非标准功能部分能力还有子能力。比如resources可以带subscribe支持订阅和listChanged支持列表变更通知。prompts和tools可以带listChanged。能力协商的规则很简单双方都有的能力才能用。如果Server想发sampling请求但Client没声明sampling能力就会失败。反过来如果Client想订阅资源但Server没声明subscribe子能力也行不通。生命周期管理MCP连接的生命周期分三个阶段初始化、操作和关闭。初始化阶段Client发起initialize请求携带三项信息。protocolVersion是客户端支持的协议版本应该是客户端支持的最新版本。capabilities是客户端能力声明。clientInfo是客户端实现信息包括名称和版本。Server收到后返回自己的protocolVersion、capabilities和serverInfo。如果Server支持Client请求的协议版本返回相同版本。如果不支持返回Server支持的最新版本。Client收到后如果不支持Server返回的版本应该断开连接。协议版本协商完成后Client发送initialized通知握手正式结束。当前最新协议版本是2025-06-18。更早的版本有2025-03-26和2024-11-05。版本间的差异主要在传输层2024-11-05用的是HTTPSSE传输2025-06-18换成了Streamable HTTP。操作阶段握手完成后进入操作阶段双方按协商好的能力和协议版本交换消息。这个阶段双方都要遵守两条规则。第一只使用协商成功的协议版本。第二只使用双方都声明了的能力。Client可以发请求tools/call、resources/read、prompts/get等和通知取消通知、进度通知等。Server可以发响应、通知日志、列表变更、资源更新等和请求sampling、elicitation。关闭阶段关闭阶段没有专门的消息靠传输层机制来终止连接。stdio传输的关闭流程是这样。Client先关闭Server子进程的输入流stdin等待Server自行退出。如果等了合理时间Server还没退出Client发SIGTERM信号。再等一段时间还不退出发SIGKILL强制终止。Streamable HTTP传输的关闭通过关闭HTTP连接实现。Client不再需要某个session时应该发HTTP DELETE请求带上Mcp-Session-Id头显式终止session。Server也可以主动终止session之后对该session的请求返回404。传输层对比MCP目前定义了两种标准传输机制。对比维度stdioStreamable HTTP适用场景本地开发、桌面应用远程服务、云部署连接方式子进程stdin/stdoutHTTP POST/GET消息分隔换行符分隔HTTP body日志输出stderrnotifications/message通知会话管理进程生命周期Mcp-Session-Id头多客户端一对一一对多流式支持不支持SSE流式响应断线重连需重启进程支持resumabilitystdio适合本地场景。Client把Server作为子进程启动通过stdin发消息从stdout读响应。好处是简单直接不用管网络。坏处是一对一每个Client要启动一个Server进程。Streamable HTTP适合远程场景。Server作为独立HTTP服务运行多个Client可以连同一个Server。支持SSE流式传输Server可以主动推送消息。有session管理机制通过Mcp-Session-Id头标识会话。协议规范建议Client尽可能支持stdio因为本地场景下stdio最简单高效。一个实际架构示例我用一个具体场景说明架构怎么用起来。假设你做了一个AI编程助手需要让LLM访问本地文件系统、查询数据库和调用外部API。-------------------------------------------------- | AI编程助手 (Host) | | | | ---------- ---------- ---------- | | | Client 1 | | Client 2 | | Client 3 | | | --------- --------- --------- | -------|---------------|---------------|---------- | stdio | stdio | HTTP | | | ----------- ----------- ----------- | FS Server | | DB Server | | API Server | | 读写本地文件 | | 查询MySQL | | 调用GitHub | ------------ ------------ ------------Host是AI编程助手应用。它创建3个Client分别连接3个Server。文件系统Server用stdio在本地运行数据库Server也用stdio本地运行GitHub API Server用Streamable HTTP部署在远程。LLM在对话中需要读取文件时Host通过Client 1调用FS Server的read_file工具。需要查数据库时通过Client 2调用DB Server的query工具。需要查GitHub仓库信息时通过Client 3调用API Server的工具。Host把三个Server的工具列表合并后统一呈现给LLMLLM不用知道背后有几个Server。常见问题与避坑第一个坑搞混Host和Client的角色。Host是应用层面的管理者Client是协议层面的连接器。一个Host内部可以有多个Client每个Client连一个Server。开发时如果你写的是Host要同时管理多个Client的生命周期。如果你写的是Server只管跟一个Client通信就行。第二个坑协议版本协商失败没处理。Client请求版本AServer返回版本BClient直接按版本A继续通信结果两边行为不一致。正确做法是检查Server返回的版本不兼容就断开。第三个坑stdio模式下Server没有正确退出。Client关闭stdin后Server应该检测到EOF并退出但有些Server代码没处理stdin的end事件进程一直挂着。Client只能靠SIGKILL强制杀掉可能导致资源没释放。Server代码里要监听stdin的end事件做清理。第四个坑HTTP模式下忘了带Mcp-Session-Id头。Streamable HTTP传输在initialize响应里返回session ID后续所有请求都要带这个头。漏了的话Server返回400 Bad Request。用SDK的话会自动处理自己写客户端容易忘。第五个坑能力协商后用了没协商的能力。比如Server代码里调了sampling但Client没声明sampling能力运行时报-32602错误。开发时用Inspector检查initialize握手消息确认双方能力声明符合预期。小结MCP的三层架构里Host管理多个Client每个Client连接一个ServerServer暴露Tools/Resources/Prompts三种能力。通信流程分初始化握手、正常操作和关闭三个阶段握手时做协议版本和能力协商。传输层支持stdio和Streamable HTTP两种方式分别适合本地和远程场景。理解这个架构的关键是搞清三个角色的边界Host管协调Client管协议Server管能力各司其职。相关推荐MCP是什么为什么2026年每个AI开发者都需要了解它JSON-RPC 2.0MCP通信的底层语言传输层详解stdio vs SSE vs Streamable HTTP